Fix stale top level synthetic package object being used in later runs #23464
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
OMG, it's amazing such huge pain and weird error gets such a small fix. I see there are tests regressions, so the jury is still out on the size and nature of the fix, but thank you for looking into it. |
They were previously fixed from crashing to erroring state, now compiling. The cause of the previous crashes looks the same as the one fixes in this PR, where the stale synthetic top level package object would be brought forward, causing other stale symbols to be used.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #13821
To explain what was happening:
We previously got a completion assertion crash, because a stale symbol (
val candidate) was brought forward into a new run, even though it should not have been, when searching for implicits. This was caused by the synthetic top level package object (file$package, generated only when top level definitions require it to, which is why the issue appeared only whentype DFBits = Longwas present) passingstillValidcheck, despite not being found in the Symbols owned by owner (package <empty>). This would cause all of the stale members of that to also be brought forward (as they would fulfill the requirements ofstillValidInOwner).The stale top level package would incorrectly pass the
(denot.is(Synthetic) && denot.is(ModuleClass) && stillValidInOwner(denot.companionClass))check in stillValidInOwner, despite companionClass of that package object being a noSymbol. Now we also check if companionClass is anoSymbolexplicitly to avoid this issue.