Skip to content

Fix signatures involving WildcardTypes #12240

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

Merged
merged 1 commit into from
Apr 28, 2021

Conversation

smarter
Copy link
Member

@smarter smarter commented Apr 27, 2021

A WildcardType never appears in the type of a tree, but it can appear
in an expected type and because TypeComparer checks if
tp1.signature consistentParams tp2.signature, we can end up calling
sigName on a WildcardType.

Before this commit, the result was either a custom type name or the
upper-bound of the wildcard, but both of these options means that
consistentParams could return false in situations where the two method
types would in fact match. We fix this by always returning
tpnme.Uninstantiated, meaning that consistentParams will always
allow a wildcard to match any other type. This does not cause any
over-approximation because the TypeComparer will always check that the
actual types match after checking that the signatures match.

Also use tpnme.ERROR instead of tpnme.Wildcard for ErrorType and NoType
to make it easier to spot their usage.

Fixes #11481.

A `WildcardType` never appears in the type of a tree, but it can appear
in an expected type and because TypeComparer checks if
`tp1.signature consistentParams tp2.signature`, we can end up calling
`sigName` on a `WildcardType`.

Before this commit, the result was either a custom type name or the
upper-bound of the wildcard, but both of these options means that
`consistentParams` could return false in situations where the two method
types would in fact match. We fix this by always returning
`tpnme.Uninstantiated`, meaning that `consistentParams` will always
allow a wildcard to match any other type. This does not cause any
over-approximation because the TypeComparer will always check that the
actual types match after checking that the signatures match.

Also use tpnme.ERROR instead of tpnme.Wildcard for ErrorType and NoType
to make it easier to spot their usage.

Fixes scala#11481.
@anatoliykmetyuk anatoliykmetyuk merged commit 17b62df into scala:master Apr 28, 2021
@anatoliykmetyuk anatoliykmetyuk deleted the fix-wildcard-sig branch April 28, 2021 09:07
@Kordyjan Kordyjan added this to the 3.0.1 milestone Aug 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Can't define case class field of PolyFunction type
3 participants