Skip to content

Hygiene of _root_ in user definitions #18050

Closed
@som-snytt

Description

@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.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions