-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
inference: limit single-level nested Type
signature
#40379
Conversation
Previously `type_more_complex` returns `false` for `Type{Type{...}}` compared against `Type{...}`. Per comment there, this should return `true`, but the code was ordered incorrect (it was also missing support for Vararg, after the recent changes). Fixes #40336 Co-authored-by: Shuhei Kadowaki <aviatesk@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, LGTM.
if isa(c, DataType) | ||
if isa(c, Core.TypeofVararg) | ||
# Tuple{Vararg{T}} --> Tuple{T} is OK | ||
return _limit_type_size(t, c.T, sources, depth, 0) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
return _limit_type_size(t, c.T, sources, depth, 0) | |
return _limit_type_size(t, unwrapva(c), sources, depth, 0) |
for the consistency with the other parts ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Keno ^
@nanosoldier |
Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. cc @christopher-dG |
Previously `type_more_complex` returns `false` for `Type{Type{...}}` compared against `Type{...}`. Per comment there, this should return `true`, but the code was ordered incorrect (it was also missing support for Vararg, after the recent changes). Fixes JuliaLang#40336 Co-authored-by: Shuhei Kadowaki <aviatesk@gmail.com>
Previously `type_more_complex` returns `false` for `Type{Type{...}}` compared against `Type{...}`. Per comment there, this should return `true`, but the code was ordered incorrect (it was also missing support for Vararg, after the recent changes). Fixes JuliaLang#40336 Co-authored-by: Shuhei Kadowaki <aviatesk@gmail.com>
Fixes the inference regression, while retaining the cases addressed by <#40379>. The same `Type`-name comparison pass (i.e. a branch of `isa(c, DataType) && t.name === c.name`) can lead to more accurate result by recursive comparison than `isType` check pass (i.e. a branch of `isType(t)`), and preferring the former over the latter fixes the regression. But just swapping the branch will lead to <#40336>, and so this PR also implements additional check to make sure `type_more_complex` still detects a single-level nesting correctly (especially, the `tt === c` parts).
Fixes the inference regression, while retaining the cases addressed by <#40379>. The same `Type`-name comparison pass (i.e. a branch of `isa(c, DataType) && t.name === c.name`) can lead to more accurate result by recursive comparison than `isType` check pass (i.e. a branch of `isType(t)`), and preferring the former over the latter fixes the regression. But just swapping the branch will lead to <#40336>, and so this PR also implements additional check to make sure `type_more_complex` still detects a single-level nesting correctly (especially, the `tt === c` parts).
Previously `type_more_complex` returns `false` for `Type{Type{...}}` compared against `Type{...}`. Per comment there, this should return `true`, but the code was ordered incorrect (it was also missing support for Vararg, after the recent changes). Fixes JuliaLang#40336 Co-authored-by: Shuhei Kadowaki <aviatesk@gmail.com>
Previously
type_more_complex
returnsfalse
forType{Type{...}}
compared against
Type{...}
. Per comment there, this should returntrue
,but the code was ordered incorrect (it was also missing support for
Vararg, after the recent changes).
Fixes #40336, Replaces #40341
@aviatesk I think this is a more complete fix, that matches the intent of the comment there.