Fix #1895: Use proper validity period for extension methods #4613
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
Efficient arrays of value classes have been abandoned for now, see scala#1558
This method was unused so far but will be used in the next commit. The validity period of a transformed denotation starts at the phase after the transformer has been run.
When we create a symbol in a DenotationTransformer, we cannot safely create it at phase `thisPhase.next` since this can lead to cycles. This is why we created extension methods at phase `thisPhase`, but they're not really valid at that point since they're only entered in their owner once the transformer has been run. This lead to stale symbol errors which were worked around in 51a458e but the fix is incomplete and does not work with scala#4604 because that PR moves the ExtensionMethods phase around. This commit removes all the workarounds and uses a simpler solution: create the symbols at phase `thisPhase` but set their validity period to match the validity of the owner transformed denotation.
|
test performance please |
|
performance test scheduled: 1 job(s) in queue, 0 running. |
|
Performance test finished successfully: Visit http://dotty-bench.epfl.ch/4613/ to see the changes. Benchmarks is based on merging with master (868d199) |
odersky
approved these changes
Jun 4, 2018
| def validFor(implicit ctx: Context): Period = | ||
| Period(ctx.runId, id, lastPhaseId) | ||
| Period(ctx.runId, id + 1, lastPhaseId) |
There was a problem hiding this comment.
At first I was scared, because it looks really hard to see all the ramifications of this change. But then I found out that the method is in fact not used at all! So do we still want to keep it?
There was a problem hiding this comment.
Yes, it's in fact used by the commit just after it as explained in the commit message: 7aa1ee2, see https://github.com/lampepfl/dotty/pull/4613/files#diff-093136d16584c89857e7cb09ec4f6518R75
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.
When we create a symbol in a DenotationTransformer, we cannot safely
create it at phase
thisPhase.nextsince this can lead to cycles. Thisis why we created extension methods at phase
thisPhase, but they'renot really valid at that point since they're only entered in their owner
once the transformer has been run. This lead to stale symbol errors
which were worked around in 51a458e but
the fix is incomplete and does not work with #4604 because that PR moves
the ExtensionMethods phase around.
This PR removes all the workarounds and uses a simpler solution:
create the symbols at phase
thisPhasebut set their validityperiod to match the validity of the owner transformed denotation.