-Vprint shows spurious root-level empty package

[som-snytt]

Compiler version

Scala compiler version 3.0.3-RC1-bin-SNAPSHOT-git-7899462 -- Copyright 2002-2021, LAMP/EPFL

Minimized code

package <empty> {
  package p {
    class C() extends Object() {}
  }
  package q {
    class D() extends Object() {}
  }
}

Output

It shows an enclosing <empty> package.

Expectation

No such enclosure. Neither Scala 2 nor Java use "empty package" to mean "nameless root thing".

Top-level definitions without packaging belong in empty package:

package <empty> {
  class C() extends Object() {}
  final lazy module val mt$package: mt$package = new mt$package()
  final module class mt$package() extends Object() { this: mt$package.type =>
    def f: Int = 42
  }
}

Taking them as nested packages justifies definitions in the empty package available to named packages in the current file.

Cf #7891

[dwijnand]

It's exactly the same in Scala 2, so I don't see how this is a problem:

$ mm i13113{a,b}.scala
==> i13113a.scala <==
package p {
  class C
}

package q {
  class D
}

==> i13113b.scala <==
class C

def f = 42
$
$ scalac -Vprint:parser i13113a.scala
[[syntax trees at end of                    parser]] // i13113a.scala
package <empty> {
  package p {
    class C extends scala.AnyRef {
      def <init>() = {
        super.<init>();
        ()
      }
    }
  };
  package q {
    class D extends scala.AnyRef {
      def <init>() = {
        super.<init>();
        ()
      }
    }
  }
}

$
$ scalac -Vprint:parser i13113b.scala
i13113b.scala:3: error: expected class or object definition
def f = 42
^
[[syntax trees at end of                    parser]] // i13113b.scala
package <empty> {
  class C extends scala.AnyRef {
    def <init>() = {
      super.<init>();
      ()
    }
  }
}

1 error

Especially given the comments in #7891.

[som-snytt]

The problem part is that "empty package" is a special construct, not just a sloppy notion of "root package".

A Scala 2 bug falls under the two wrongs not making a right rule.

It might matter in Scala 3 where reasoning about top-level scoping is more tricky, if there are file-based rules.

Here are two files, it's pretty obvious that different nomenclature is needed for "two packages in a file". I chose "nestle" for the pun on the Swiss food giant. Maybe the point is that after typer, file scope doesn't matter any more. Visibility is a done deal.

result of nestle.scala after typer:
package <empty> {
  package p {
    class C() extends Object() {}
  }
  package q {
    class D() extends Object() {}
    final lazy module val nestle$package: q.nestle$package$ = new q.nestle$package$()
    final module class nestle$package$() extends Object() { this: q.nestle$package.type =>
      def f: Unit = println("hi")
    }
  }
}
result of unnestle.scala after typer:
package p {
  class X() extends Object() {}
}

[dwijnand]

I'm not sure what fix you're vouching for? A change to the printing to hide away that they're actually bundled in an "empty" package? Or are you saying that parsing should, perhaps, return a Thicket(pkgP, pkgQ) in the nestle case?

[dwijnand]

Nvm, this is desired: #13520 (comment)