Hygiene of _root_ in user definitions

[som-snytt]

Compiler version

3.3.0

Minimized code

package p {
  package _root_ {
    object X
  }
}

Output

4 |    object X
  |    ^
  |    Not found: type X

Expectation

_root_ is an ordinary identifier except in a selection _root_.x, so this should just work, especially since the example below works.

Example is from https://github.com/scala/scala/blob/2.13.x/test/files/neg/t6217c.scala

Dotty compiles the example in scala/bug#12508 where the user packaging is top-level:

package _root_ {
  class C {
    val _root_ = 42
  }
}
package _root_.p {
  class C
}

That produces packages _root_ and _root_.p.

The latter example is "harder" in the sense that user's _root_ does clash with any possible selection; that is, _root_._root_.C is required to disambiguate.

Of course, no one writes code like this, but maybe it indicates an issue with lookups for the definition of object X.

[odersky]

It's because of this clause in Typer.typedIdent:

    // Shortcut for the root package, this is not just a performance
    // optimization, it also avoids forcing imports thus potentially avoiding
    // cyclic references.
    if (name == nme.ROOTPKG)
      return tree.withType(defn.RootPackage.termRef)

See also: #18020 (comment)