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

inference: limit single-level nested Type signature #40379

Merged
merged 1 commit into from
Apr 9, 2021
Merged

Conversation

vtjnash
Copy link
Member

@vtjnash vtjnash commented Apr 6, 2021

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, Replaces #40341

@aviatesk I think this is a more complete fix, that matches the intent of the comment there.

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>
Copy link
Member

@aviatesk aviatesk left a 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)
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
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 ?

Copy link
Member Author

Choose a reason for hiding this comment

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

@Keno ^

@mbauman mbauman added the compiler:inference Type inference label Apr 8, 2021
@vtjnash
Copy link
Member Author

vtjnash commented Apr 8, 2021

@nanosoldier runbenchmarks(ALL, vs=":master")

@nanosoldier
Copy link
Collaborator

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. cc @christopher-dG

@vtjnash vtjnash merged commit c2ec70c into master Apr 9, 2021
@vtjnash vtjnash deleted the jn/fix40336 branch April 9, 2021 03:10
ElOceanografo pushed a commit to ElOceanografo/julia that referenced this pull request May 4, 2021
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>
antoine-levitt pushed a commit to antoine-levitt/julia that referenced this pull request May 9, 2021
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>
aviatesk added a commit that referenced this pull request May 28, 2021
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).
aviatesk added a commit that referenced this pull request May 31, 2021
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).
johanmon pushed a commit to johanmon/julia that referenced this pull request Jul 5, 2021
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler:inference Type inference
Projects
None yet
Development

Successfully merging this pull request may close these issues.

limit_type_size failure for Type{Type{..}}
5 participants