-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Always use adapted type in withDenotation #16901
Merged
Merged
Conversation
This file contains 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
When creating a NamedType with a given overloaded denotation, make sure that the type has a Name as designator. This prevents accidentally overwriting a more precise symbolic TermRef that refers to one specific alternative of the denotation. This might be enough to fix scala#16884. It would be great if we could maintain the general invariant that NamedTypes with overloaded denotations always have names as designators. But that looks very hard when we take into account that we need to update named types to new runs. A type might have a single denotation in one round and an overloaded one in the next.
Make infoDependsOnPrefix return true even if the prefix is the ThisType of the enclosing class, in case that class has a selftype which refines the binding of an abstract type. This allows to implement withDenot without overwriting a NamedType's state.
odersky
changed the title
Tweak withDenot for overloaded denotations
Always use adapted type in withDenotation
Feb 13, 2023
Also consider non-final term members with self type refinements for infoDependsOnPrefix
smarter
approved these changes
Feb 16, 2023
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can confirm that this fixes #16884 in practice.
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 creating a NamedType with a given overloaded denotation, make sure that the type has a Name as designator. This prevents accidentally overwriting a more precise symbolic TermRef that refers to one specific alternative of the denotation.
This might be enough to fix #16884.
EDIT: It wasn't enough but the second commit 46e82dd should fix it. The second commit never overwrites in
withDenot
. It can do that because we fixinfoDependsOnPrefix
to work correctly for abstract types that are refined in a self type. It turned out that previously we needed some TypeRefs to keep their Name designators because that way we would recompute their info with amember
operation. If these TypeRefs had a symbol designator they would be recomputed wrongly bysymd.current
infromDesignator
because the precedinginfoDependsOnPrefix
test was faulty.It would be great if we could maintain the general invariant that NamedTypes with overloaded denotations always have names as designators. But that looks very hard when we take into account that we need to update named types to new runs. A type might have a single denotation in one round and an overloaded one in the next.