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

Normalize for underlyingClassRef #20259

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

EugeneFlesselle
Copy link
Contributor

Related to #20258

Here too, I would be fine with not normalizing,
but in that case pos/i15827 should become a neg test.

Related to scala#20258
Here too, I would be fine with not normalizing,
but in that case pos/i15827 should become a neg test.
@@ -1584,7 +1584,8 @@ object Types extends TypeUtils {
else if (tp.symbol.isAliasType) tp.underlying.underlyingClassRef(refinementOK)
else NoType
case tp: AppliedType =>
if (tp.tycon.isLambdaSub) NoType
if tp.isMatchAlias then tp.tryNormalize.underlyingClassRef(refinementOK)
Copy link
Member

@dwijnand dwijnand Apr 24, 2024

Choose a reason for hiding this comment

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

For this and 20258, what if it's a match alias that doesn't normalise, don't you want to cascade to the later cases?

We don't really have an efficient way to do that (&& tp.tryNormalize.exists :-/)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It might be incorrect but I had intentionally not cascaded to the later cases here. I don't think any of them would return something other than NoType on an unreducible match type.

Copy link
Member

@sjrd sjrd left a comment

Choose a reason for hiding this comment

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

I think this goes against the spec. There is nothing in the spec supporting reducing match types when determining whether a type is a class type or not. And underlyingClassRef is exactly the implementation of "is it a class type", AFAICT.

So yes, pos/i15827.scala should probably be a neg test.

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.

None yet

3 participants