-
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
Properly handle SAM types with wildcards #18201
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
Will this be backport to 3.3.x? |
|
Previously there were two separate checks for contextual function types as result types: one in SAMType for non-PartialFunctions and one in ExpandSAM for PartialFunctions. This is replaced by a single check (with a detailed error message like we already had for PartialFunctions).
When typing a closure with an expected type containing a wildcard, the closure type itself should not contain wildcards, because it might be expanded to an anonymous class extending the closure type (this happens on non-JVM backends as well as on the JVM itself in situations where a SAM trait does not compile down to a SAM interface). We were already approximating wildcards in the method type returned by the SAMType extractor, but to fix this issue we had to change the extractor to perform the approximation on the expected type itself to generate a valid parent type. The SAMType extractor now returns both the approximated parent type and the type of the method itself. The wildcard approximation analysis relies on a new `VarianceMap` opaque type extracted from Inferencing#variances. Fixes scala#16065. Fixes scala#18096.
dwijnand
approved these changes
Jul 15, 2023
smarter
added a commit
to dotty-staging/dotty
that referenced
this pull request
Jul 31, 2023
This was dropped in scala#18201 which restricted SAM types to valid parent types, but it turns out that there is code in the wild that relies on refinements being allowed here. To support this properly, we had to enhance ExpandSAMs to move refinements into type members to pass Ycheck (previous Scala 3 releases would accept the code in tests/run/i18315.scala but fail Ycheck). Fixes scala#18315.
smarter
added a commit
to dotty-staging/dotty
that referenced
this pull request
Jul 31, 2023
This was dropped in scala#18201 which restricted SAM types to valid parent types, but it turns out that there is code in the wild that relies on refinements being allowed here. To support this properly, we had to enhance ExpandSAMs to move refinements into type members to pass Ycheck (previous Scala 3 releases would accept the code in tests/run/i18315.scala but fail Ycheck). Fixes scala#18315.
smarter
added a commit
that referenced
this pull request
Aug 1, 2023
This was dropped in #18201 which restricted SAM types to valid parent types, but it turns out that there is code in the wild that relies on refinements being allowed here. To support this properly, we had to enhance ExpandSAMs to move refinements into type members to pass Ycheck (previous Scala 3 releases would accept the code in tests/run/i18315.scala but fail Ycheck). Fixes #18315. This should be backported to any branch where #18201 is backported.
Kordyjan
added a commit
that referenced
this pull request
Dec 8, 2023
Backports #18201 to the LTS branch. PR submitted by the release tooling.
WojciechMazur
pushed a commit
to WojciechMazur/dotty
that referenced
this pull request
Sep 6, 2024
This was dropped in scala#18201 which restricted SAM types to valid parent types, but it turns out that there is code in the wild that relies on refinements being allowed here. To support this properly, we had to enhance ExpandSAMs to move refinements into type members to pass Ycheck (previous Scala 3 releases would accept the code in tests/run/i18315.scala but fail Ycheck). Fixes scala#18315.
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 typing a closure with an expected type containing a wildcard, the closure
type itself should not contain wildcards, because it might be expanded to an
anonymous class extending the closure type (this happens on non-JVM backends as
well as on the JVM itself in situations where a SAM trait does not compile down
to a SAM interface).
We were already approximating wildcards in the method type returned by the
SAMType extractor, but to fix this issue we had to change the extractor to
perform the approximation on the expected type itself to generate a valid
parent type. The SAMType extractor now returns both the approximated parent
type and the type of the method itself.
The wildcard approximation analysis relies on a new
VarianceMap
opaque typeextracted from Inferencing#variances.
Fixes #16065.
Fixes #18096.