Complete owners of type parameters before parameters themselves #10972
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
Fixes scala#10967 I minimized scala#10967 further to: ```scala trait SomeTrait trait CollBase[CC1[A2 <: SomeTrait]] { val companion: CollCompanion[CC1] } trait CollCompanion[CC2[A <: SomeTrait]] ``` What happened was: 1. the compiler tries to typecheck `companion` 2. this means needs to check `CollCompanion[CC1]` 3. this means it needs to complete the type parameter `CC2` of CollCompanion in order to make sure the argument is CC1 is kind correct. 4. this means we complete type parameter `A` of `CC2` 4. checking the type parameter requires checking the owner class `CollCompanion`. 5. And this leads back to `CC2`, hence the cycle. Note that if the definitions of `CollBase` and `CollCompanion` appear in reverse order, no cycle results, since then `CollCompanion` and its type parameters were completed before completing `companion`. To break the cycle, we can complete the owner of a type parameter before starting completion of the parameter. Furthermore, we need to do this only in Namer, which is where the complex checking patterns are. I have not tried to also treat symbols that are not type definitions that way. It's not necessary to fix scala#10967 but it might help for other cycles (or it might cause them, these things are tricky!). I did try to make the behavior universal for all completers, not just Namers, but that caused crashes immediately.
|
test performance please |
smarter
approved these changes
Jan 5, 2021
|
performance test scheduled: 10 job(s) in queue, 1 running. |
|
Performance test finished successfully: Visit http://dotty-bench.epfl.ch/10972/ to see the changes. Benchmarks is based on merging with master (234cb00) |
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 #10967
Fixes #10638
I minimized #10967 further to:
What happened was:
companionCollCompanion[CC1]CC2of CollCompanion in order to make sure the argument is CC1 is kind correct.AofCC2CollCompanion.CC2, hence the cycle.Note that if the definitions of
CollBaseandCollCompanionappear in reverse order,no cycle results, since then
CollCompanionand its type parameters were completed beforecompleting
companion.To break the cycle, we can complete the owner of a type parameter before starting
completion of the parameter. Furthermore, we need to do this only in Namer, which is
where the complex checking patterns are. I have not tried to also treat symbols that
are not type definitions that way. It's not necessary to fix #10967 but it might help
for other cycles (or it might cause them, these things are tricky!). I did try to
make the behavior universal for all completers, not just Namers, but that caused
crashes immediately.