Skip to content
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 2 commits into from
Jul 15, 2023
Merged

Conversation

smarter
Copy link
Member

@smarter smarter commented Jul 13, 2023

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 #16065.
Fixes #18096.

@He-Pin
Copy link

He-Pin commented Jul 14, 2023

Will this be backport to 3.3.x?

@smarter
Copy link
Member Author

smarter commented Jul 14, 2023

main is still 3.3.x for now so yes

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.
@smarter smarter merged commit 4851278 into scala:main Jul 15, 2023
17 checks passed
@smarter smarter deleted the fix-i16065-4 branch July 15, 2023 18:29
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 Kordyjan added this to the 3.4.0 milestone Aug 1, 2023
Kordyjan added a commit that referenced this pull request Dec 8, 2023
Backports #18201 to the LTS branch.

PR submitted by the release tooling.
@Kordyjan Kordyjan modified the milestones: 3.4.0, 3.3.2 Dec 14, 2023
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
Labels
None yet
Projects
None yet
4 participants