|
|
The compiler-in-residence has always been a sketchy affair;
FSC and REPL offers a bounty of bugs that exploit the menagerie
of time-travel mechanisms in play for symbols' metadata (type, flags,
name and owner.) but are often cleverly masked by optimizations in
the compiler based on reference equality.
The latest: an innocuous change in Erasure:
https://github.com/scala/scala/commit/d8b96bb8#commitcomment-3995163
means that some `ErasureMap`-s over `MethodType`-s are now true
identities (as `UnitTpe` is always the same object, whereas
`erasedTypeRef(UnitClass)` returns an different `TypeRef` each
time.)
This, in turn, enables `TypeMap#mapOver` to reuse
the existing enclosing type, and so on. On such subtleties hinge
further optimizations, such as whether or not a given phase's
`InfoTransformer` needs to add an entry in a symbols type history.
When the REPL (or FSC / Presentation Compiler) creates a new
`Run`, `Symbol#rawInfo` tries to adapt the entries in the type
history for the new run. For packages, this was taken to be a
no-op; each entry is marked as being valid in the new run and
no further action is taken. This logic lurks in `adaptInfos`.
But, when the namer enters a new symbol in a package, it
*mutates* the Scope of that package classes info `enteringTyper`.
So the later entries in the type history *must* be invalidated
and recomputed.
We have two choices for a fix:
1) modify `Namers#enterInScope` to blow away the subsequent
type history for the owning symbol after inserting the
new member. Something like `owner.setInfo(owner.info)` would
have the desired effect.
2) Change `adaptInfos` to be more conservative when it comes
to package classes, and retain only the oldest entry in the
type history.
This commit goes for option 2.
|
