typelimits: Prevent accidental infinite growth in size limiting #48421
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
vtjnash
reviewed
Jan 26, 2023
vtjnash
reviewed
Jan 26, 2023
vtjnash
added
the
needs pkgeval
|
Let's try this version. |
|
@nanosoldier |
|
Your package evaluation job has completed - possible new issues were detected. |
|
I don't see anything that looks inference quality related |
vtjnash
added
merge me
aviatesk
approved these changes
Jan 30, 2023
There's a few related issues here:
1. Type size limiting depended on the identity of contained TypeVars.
E.g. `Base.rewrap_unionall(Foo{Base.unwrap_unionall(A)}, A)`, would
not be limited while the equivalent with typevars substituted would be.
This is obviously undesirable because the identity of typevars is an
implementation detail.
2. We were forcing `tupledepth` to 1 in the typevar case to allow replacing
typevars by something concrete. However, this also allowed typevars being
replaced by something derived from `sources`, which could be huge and itself
contain TypeVars, allowing infinite growth.
3. There was a type query that was run on types containg free typevars. This
would have asserted in a debug build and gave wrong answers in a release build.
Fix all three issues, which together addresses an inference non-termination seen in #48329.
DilumAluthge
force-pushed
the
kf/badsizelimit
branch
from
4e8a388 to
b77fab2
Compare
|
Huh, I thought we had merged this. This was supposed to have been merged before #48329, whoops. |
DilumAluthge
removed
the
merge me
vtjnash
added a commit
that referenced
this pull request
Mar 27, 2023
In #48421 we removed all limits from apply_type, but that can lead to significant expression complexity which may be hard for subtyping to deal with. Try adding a heuristic size limiting constraint. Also do a bunch of code rearrangement and slight cleanup so that this change does not make the logic look complicated here. Solves #49127
vtjnash
added a commit
that referenced
this pull request
Apr 4, 2023
In #48421 we removed all limits from apply_type, but that can lead to significant expression complexity which may be hard for subtyping to deal with. Try adding a heuristic size limiting constraint. Also do a bunch of code rearrangement and slight cleanup so that this change does not make the logic look complicated here. Solves #49127
aviatesk
pushed a commit
that referenced
this pull request
Apr 10, 2023
In #48421 we removed all limits from apply_type, but that can lead to significant expression complexity which may be hard for subtyping to deal with. Try adding a heuristic size limiting constraint. Also do a bunch of code rearrangement and slight cleanup so that this change does not make the logic look complicated here. Solves #49127
Xnartharax
pushed a commit
to Xnartharax/julia
that referenced
this pull request
Apr 19, 2023
In JuliaLang#48421 we removed all limits from apply_type, but that can lead to significant expression complexity which may be hard for subtyping to deal with. Try adding a heuristic size limiting constraint. Also do a bunch of code rearrangement and slight cleanup so that this change does not make the logic look complicated here. Solves JuliaLang#49127
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There's a few related issues here:
Base.rewrap_unionall(Foo{Base.unwrap_unionall(A)}, A), would not be limited while the equivalent with typevars substituted would be. This is obviously undesirable because the identity of typevars is an implementation detail.tupledepthto 1 in the typevar case to allow replacing typevars by something concrete. However, this also allowed typevars being replaced by something derived fromsources, which could be huge and itself contain TypeVars, allowing infinite growth.Fix all three issues, which together addresses an inference non-termination seen in #48329.