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

Don't allow wildcard types in constraints #12703

Merged
merged 14 commits into from
Jun 9, 2021
Merged

Conversation

odersky
Copy link
Contributor

@odersky odersky commented Jun 3, 2021

Fixes #12677

compiler/src/dotty/tools/dotc/core/TypeComparer.scala Outdated Show resolved Hide resolved
Comment on lines +144 to +145
* The idea is that under either of these conditions we are not interested
* in creating a fresh type variable to replace the wildcard. I verified
Copy link
Member

@smarter smarter Jun 7, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not clear to me why useNecessaryEither is treated specially here, is there a good justification or test case that illustrates this? Also in practice we also call necessaryEither when inferring GADTs:
https://github.com/lampepfl/dotty/blob/a82af21ff48ea07dbae042239286e5d80ef0e92e/compiler/src/dotty/tools/dotc/core/TypeComparer.scala#L1564
Should that condition also appear here? /cc @abgruszecki

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it probably should. Perhaps no GADT tests failed, because the interaction of GADTs and wildcards is undertested.

As a side remark, I'm not sure when exactly we should consider useNecessaryEither in separation from the GADT mode. The name doesn't help either in reminding that we should do both. Perhaps we should hide this condition behind a definition and rename useNecessaryEither?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe 12677 is the test case that fails otherwise.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure about GADT inference. Does it even come up?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I verified that all tests pass with or without the added condition ctx.mode.is(Mode.GadtConstraintInference). Someone else could go to the bottom of this in a separate PR.

@@ -34,6 +34,9 @@ object Config {
*/
inline val checkConstraintsPropagated = false

/** Check that constraint bounds do not contain wildcard types */
inline val checkNoWildcardsInConstraint = true
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume this should be set to false before merging?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, it's false in latest version

@@ -46,7 +49,7 @@ object Config {
* compiling all of dotty together (source seems to be in GenBCode which
* accesses javac's settings.)
*
* It is recommended to turn this option on only when chasing down
* It is recommended to turn this option on only w zhen chasing down
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* It is recommended to turn this option on only w zhen chasing down
* It is recommended to turn this option on only when chasing down

@smarter smarter assigned odersky and unassigned smarter Jun 7, 2021
Copy link
Member

@smarter smarter left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, I'll let @abgruszecki figure out if he can make a gadt-version of i12677.scala :).

@smarter smarter merged commit b546ece into scala:master Jun 9, 2021
@smarter smarter deleted the fix-12677 branch June 9, 2021 11:01
@Kordyjan Kordyjan added this to the 3.0.2 milestone Aug 2, 2023
@soronpo
Copy link
Contributor

soronpo commented Mar 15, 2024

Causes regression #19955

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.

Scala 2.13 regression: Path-dependent type of an implicit is lost
5 participants