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

Treat Refinements more like AndTypes #12317

Merged
merged 4 commits into from
May 4, 2021
Merged

Conversation

odersky
Copy link
Contributor

@odersky odersky commented May 3, 2021

Fixes #12306

When comparing with an AndType on the left and a RefinedType on the right,
decompose the right hand side into an AndType of types that have a single
refinement each. This makes sure we lose the least possible information in the
necessary subsequent either call.

This is a much better fix than #12316.

Fixes scala#12306

When comparing with an AndType on the left and a RefinedType on the right,
decompose the right hand side into an AndType of types that have a single
refinement each. This makes sure we lose the least information in the
necessary subsequent `either` call.
Copy link
Contributor

@abgruszecki abgruszecki left a comment

Choose a reason for hiding this comment

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

I've thought about this, tried to find cases where it would go wrong and I think everything looks good.

case tp: AndType => true
case OrType(tp1, tp2) => containsAnd(tp1) || containsAnd(tp2)
case tp: TypeParamRef => containsAnd(bounds(tp).hi)
case tp: TypeRef => containsAnd(tp.info.hiBound) || tp.symbol.onGadtBounds(gbounds => containsAnd(gbounds.hi))
Copy link
Contributor

Choose a reason for hiding this comment

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

Ah, interesting. We always compare with GADT bounds in frozen constraint, but that doesn't end up mattering, right? That is: do I understand correctly that even if we're not inferring constraints, we need to break down structural types on the RHS to properly check if there's subtyping between the left- and right-hand sides?

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 think the same reasoning applies: If we end up comparing GADT constraints we need necessaryEither, and that means we need to decompose the RHS as much as possible so that necesssaryEither is sound.

@odersky odersky merged commit 1440699 into scala:master May 4, 2021
@odersky odersky deleted the fix-12306-v2 branch May 4, 2021 10:44
@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.

Bug at type inference for structural types.
3 participants