Skip to content

Fix substParam(s) #16082

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

Closed
wants to merge 1 commit into from
Closed

Fix substParam(s) #16082

wants to merge 1 commit into from

Conversation

odersky
Copy link
Contributor

@odersky odersky commented Sep 21, 2022

The substParam and substParams operations overlooked a case: If we substitute P := T and we have a type variable A with origin P then A should map to T as well. Previously, it didn't, which means that substParam(s) could break the link between a type variable and the type parameter it stands for. This gives more freedoms to instantiate type variables than allowed so it can mask type errors.

The `substParam` and `substParams` overlooked a case: If we substitute P := T and
we have a type variable A with origin P then A should map to T as well. Previously,
it didn't  which means that substParam(s) could break the link between a type
variable and the type parameter it stands for. This gives more freedoms to instantiate
type variables than allowed so it can mask type errors.
@odersky odersky marked this pull request as ready for review September 21, 2022 09:47
@odersky
Copy link
Contributor Author

odersky commented Sep 21, 2022

I noticed this when working on #16042. Any attempt to do fixes to get dependencies right would break the CB. I thought first my changes were the problem, but in fact my fixes to dependencies also worked around the soundness hole addressed by this PR. And I believe that tightening of the rules is what broke the CB. So, unfortunately, it seems we will have some type errors in the CB that were previously not detected and now have to be fixed.

@odersky
Copy link
Contributor Author

odersky commented Sep 21, 2022

@smarter Or can you see a legitimate reason why substituting type parameters should leave associated type variables out? The problem seems to arise in replace.

@odersky
Copy link
Contributor Author

odersky commented Sep 22, 2022

It turns out empirically that this introduces errors where there are none.

@odersky odersky closed this Sep 22, 2022
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.

1 participant