In TASTy, a symbolic package can either be encoded or unencoded

[bishabosha]

Depending on if the package was declared in source, or found on the classpath, packages can be encoded differently in TASTy

Compiler version

3.1.1

Minimized code

Example 1

If we compile this file with a clean classpath, then in TASTy we will have a package declaration for symbollic_>>

package symbollic_>>

class ::

If we instead compile the file to out, then recompile the file with out on the classpath, we will have a package declaration in TASTy for symbollic_$greater$greater.

Example 2

with example 1 from a prior compilation on the classpath, compile the following:

class Bar:
  println(new symbollic_>>.::())

in TASTy all references to symbollic_>>.:: are listed as symbollic_$greater$greater.::, i.e. only the package name got encoded

Expectation

Edit: we should always see encoded unencoded package names in TASTy.

[bishabosha]

cc @sjrd for your opinion

[sjrd]

we should always see encoded package names in TASTy.

We should always see non encoded names in tasty, to be consistent with everything else.

[bishabosha]

We should always see non encoded names in tasty, to be consistent with everything else.

Edit: I see now that scalac/dotc just treats the encoded/unencoded identifiers as equivalent in source code when looking up a symbol

[odersky]

The problem is that that encoding is lossy. So if we want to see non-encoded names in tasty, we'd have to interpret directory names with embedded $greater etc as operators. Not sure we want to do that.

I don't think I have the time to work on this though.

[bishabosha]

we'd have to interpret directory names with embedded $greater etc as operators. Not sure we want to do that.

Encoded top level classes from Java are already decoded to symbolic names so I don't think there will be any undiscovered issue here

[bishabosha]

Alternate solution for lossy decoding is to block symbolic package names in source code, (unless we can somehow reuse platformName for a package?) I do not know how common they are

[bishabosha]

• ok after some discussion off GitHub, we decided to always encode the package name before it reaches tasty

[bishabosha]

another food for thought: when recompiling from the classpath, we do not encode selections from a package, even though the package is declared as being encoded:

// lib_1.scala

package fully_+.symbolic_>>.package_*

class |+|

// lib-b_2.scala - overriding the same symbol, but reading package from classpath

package fully_+.symbolic_>>.package_*

class |+|

// app_3.scala

package example

class Example:
  def foo: fully_+.symbolic_>>.package_*.|+| = new fully_+.symbolic_>>.package_*.|+|()

in 3.1.1 we get the following tasty output for example.Example, notice that the package name is encoded in a SELECTin (via signature), and in a TERMREFpkg, but SELECT of symbolic package are not encoded:

/cc @sjrd

     0: PACKAGE(75)
     2:   TERMREFpkg 1 [example]
     4:   TYPEDEF(71) 2 [Example]
     7:     TEMPLATE(50)
     9:       APPLY(10)
    11:         SELECTin(8) 9 [<init>[Signed Signature(List(),java.lang.Object) @<init>]]
    14:           NEW
    15:             TYPEREF 7 [Object]
    17:               TERMREFpkg 6 [java[Qualified . lang]]
    19:           SHAREDtype 15
    21:       DEFDEF(7) 3 [<init>]
    24:         EMPTYCLAUSE
    25:         TYPEREF 10 [Unit]
    27:           TERMREFpkg 11 [scala]
    29:         STABLE
    30:       DEFDEF(27) 12 [foo]
    33:         SELECTtpt 13 [|+|]
    35:           SELECT 14 [package_*]
    37:             SELECT 15 [symbolic_>>]
    39:               TERMREFpkg 16 [fully_$plus]
    41:         APPLY(16)
    43:           SELECTin(14) 22 [<init>[Signed Signature(List(),fully_$plus.symbolic_$greater$greater.package_$times.|+|) @<init>]]
    46:             NEW
    47:               SELECTtpt 13 [|+|]
    49:                 SELECT 14 [package_*]
    51:                   SELECT 15 [symbolic_>>]
    53:                     SHAREDtype 39
    55:             TYPEREF 13 [|+|]
    57:               TERMREFpkg 20 [fully_$plus[Qualified . symbolic_$greater$greater][Qualified . package_$times]]
    59:     ANNOTATION(16)
    61:       TYPEREF 23 [SourceFile]
    63:         TERMREFpkg 27 [scala[Qualified . annotation][Qualified . internal]]
    65:       APPLY(10)
    67:         SELECTin(6) 31 [<init>[Signed Signature(List(java.lang.String),scala.annotation.internal.SourceFile) @<init>]]
    70:           NEW
    71:             SHAREDtype 61
    73:           SHAREDtype 61
    75:         STRINGconst 32 [app.scala]

[bishabosha]

alternative fix proposed: make a warning when the package name declared in source contains symbolic characters