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

Fix higher-order unification incorrectly substituting tparams #16181

Merged
merged 1 commit into from
Oct 15, 2022

Conversation

smarter
Copy link
Member

@smarter smarter commented Oct 13, 2022

When creating a fresh type lambda for the purpose of higher-order type inference, we incorrectly substituted references to type parameters before this commit. We want to construct:

bodyArgs := otherArgs.take(d), T_0, ..., T_k-1
[T_0, ..., T_k-1] =>> otherTycon[bodyArgs]

For this type to be valid, we need the bounds of T_i to be the bounds of the (d+i) type parameter of otherTycon after substituting references to each type parameter of otherTycon by the corresponding argument in bodyArgs.

The previous implementation incorrectly substituted only the last k type parameters, this was not enough for correctness. It could also lead to a crash because it called integrate which implicitly assumes it is passed a full list of type parameters (this is now documented).

Fixes #15983.

When creating a fresh type lambda for the purpose of higher-order type
inference, we incorrectly substituted references to type parameters
before this commit. We want to construct:

    bodyArgs := otherArgs.take(d), T_0, ..., T_k-1
    [T_0, ..., T_k-1] =>> otherTycon[bodyArgs]

For this type to be valid, we need the bounds of `T_i` to be the bounds of
the (d+i) type parameter of `otherTycon` after substituting references to
each type parameter of `otherTycon` by the corresponding argument in `bodyArgs`.

The previous implementation incorrectly substituted only the last `k` type
parameters, this was not enough for correctness. It could also lead to a crash
because it called `integrate` which implicitly assumes it is passed a full list
of type parameters (this is now documented).

Fixes scala#15983.
Copy link
Contributor

@odersky odersky left a comment

Choose a reason for hiding this comment

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

Tricky, but looks OK to me.

@odersky odersky merged commit 4c46cee into scala:main Oct 15, 2022
@odersky odersky deleted the fix-15983-alt branch October 15, 2022 14:55
@Kordyjan Kordyjan added this to the 3.2.2 milestone Aug 1, 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.

Crash with dependent types and match type
3 participants