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

Wrong Vararg expansion in type intersection #37257

Closed
martinholters opened this issue Aug 28, 2020 · 0 comments · Fixed by #46446
Closed

Wrong Vararg expansion in type intersection #37257

martinholters opened this issue Aug 28, 2020 · 0 comments · Fixed by #46446
Labels
types and dispatch Types, subtyping and method dispatch

Comments

@martinholters
Copy link
Member

julia> T = Tuple{Val{N}, Any, Any, Vararg{Any,N}} where N
Tuple{Val{N},Any,Any,Vararg{Any,N}} where N

julia> typeintersect(T, Tuple{Val{1}, Vararg{Any}})
Tuple{Val{1},Any,Any,Any,Any,Any}

julia> typeintersect(T, Tuple{Val{1}, Any, Vararg{Any}})
Tuple{Val{1},Any,Any,Any,Any}

julia> typeintersect(T, Tuple{Val{1}, Any, Any, Vararg{Any}})
Tuple{Val{1},Any,Any,Any}

Clearly, the result should be Tuple{Val{1},Any,Any,Any} in all three cases.

Of course, this can have an impact on inference, e.g.

julia> foo(::Val{N}, unused, args::Vararg{Any,N}) where {N} = (Val(N), args)
foo (generic function with 1 method)

julia> code_warntype(foo, Tuple{Val{1}, Any, Vararg}) # good
Variables
  #self#::Core.Const(foo, false)
  #unused#::Core.Const(Val{1}(), false)
  unused::Any
  args::Tuple{Any}

Body::Tuple{Val{1},Tuple{Any}}
1%1 = Main.Val($(Expr(:static_parameter, 1)))::Core.Const(Val{1}(), false)
│   %2 = Core.tuple(%1, args)::Core.PartialStruct(Tuple{Val{1},Tuple{Any}}, Any[Core.Const(Val{1}(), false), Tuple{Any}])
└──      return %2

julia> code_warntype(foo, Tuple{Val{1}, Vararg}) # bad
Variables
  #self#::Core.Const(foo, false)
  #unused#::Core.Const(Val{1}(), false)
  unused::Any
  args::Tuple{Any,Any}

Body::Tuple{Val{_A} where _A,Tuple{Any,Any}}
1%1 = Main.Val($(Expr(:static_parameter, 1)))::Val{_A} where _A
│   %2 = Core.tuple(%1, args)::Tuple{Val{_A} where _A,Tuple{Any,Any}}
└──      return %2

Note that in the bad case, not only is inference of the first return value needlessly imprecise (because N wasn't fixed), but the type of the second return value is plain wrong.

I've stumbled upon this when looking at suboptimal inference of this constructor:

function BitArray{N}(::UndefInitializer, dims::Vararg{Int,N}) where N

So this is not a purely theoretical issue.

@martinholters martinholters added the types and dispatch Types, subtyping and method dispatch label Aug 28, 2020
N5N3 added a commit to N5N3/julia that referenced this issue Aug 23, 2022
The type `var` might be switched during intersection.
Thus previous result looks order dependent.

In fact, we should always return the shorter `Vararg` length.
As former terms has been taken care by `intersect_tuple`.

Also fix JuliaLang#37257
N5N3 added a commit to N5N3/julia that referenced this issue Aug 23, 2022
The type `var` might be switched during intersection. Thus previous result looks order dependent.

When we intersect 2 `Vararg`s' length, we should always return the shorter one.
As we has consumed the extra elements in `intersect_tuple`.

Also fix JuliaLang#37257
N5N3 added a commit to N5N3/julia that referenced this issue Aug 23, 2022
The type `var` might be switched during intersection. Thus previous result looks order dependent.

When we intersect 2 `Vararg`s' length, we should always return the shorter one.
As we has consumed the extra elements in `intersect_tuple`.

Also fix JuliaLang#37257
N5N3 added a commit to N5N3/julia that referenced this issue Aug 24, 2022
The type `var` might be switched during intersection. Thus previous result looks order dependent.

When we intersect 2 `Vararg`s' length, we should always return the shorter one.
As we has consumed the extra elements in `intersect_tuple`.

Also fix JuliaLang#37257
N5N3 added a commit to N5N3/julia that referenced this issue Aug 24, 2022
The type `var` might be switched during intersection. Thus previous result looks order dependent.

When we intersect 2 `Vararg`s' length, we should always return the shorter one.
As we has consumed the extra elements in `intersect_tuple`.

Also fix JuliaLang#37257
N5N3 added a commit to N5N3/julia that referenced this issue Aug 24, 2022
The type `var` might be switched during intersection. Thus previous result looks order dependent.

When we intersect 2 `Vararg`s' length, we should always return the shorter one.
As we has consumed the extra elements in `intersect_tuple`.

Also fix JuliaLang#37257
N5N3 added a commit to N5N3/julia that referenced this issue Aug 24, 2022
The type `var` might be switched during intersection. Thus previous result looks order dependent.

When we intersect 2 `Vararg`s' length, we should always return the shorter one.
As we has consumed the extra elements in `intersect_tuple`.

Also fix JuliaLang#37257
N5N3 added a commit to N5N3/julia that referenced this issue Aug 24, 2022
The type `var` might be switched during intersection. Thus previous result looks order dependent.

When we intersect 2 `Vararg`s' length, we should always return the shorter one.
As we has consumed the extra elements in `intersect_tuple`.

Also fix JuliaLang#37257
N5N3 added a commit to N5N3/julia that referenced this issue Aug 24, 2022
The type `var` might be switched during intersection. Thus previous result looks order dependent.

When we intersect 2 `Vararg`s' length, we should always return the shorter one.
As we has consumed the extra elements in `intersect_tuple`.

Also fix JuliaLang#37257
N5N3 added a commit to N5N3/julia that referenced this issue Aug 29, 2022
The type `var` might be switched during intersection. Thus previous result looks order dependent.

When we intersect 2 `Vararg`s' length, we should always return the shorter one.
As we has consumed the extra elements in `intersect_tuple`.

Also fix JuliaLang#37257
N5N3 added a commit to N5N3/julia that referenced this issue Aug 31, 2022
The type `var` might be switched during intersection. Thus previous result looks order dependent.

When we intersect 2 `Vararg`s' length, we should always return the shorter one.
As we has consumed the extra elements in `intersect_tuple`.

Also fix JuliaLang#37257

Co-Authored-By: Jameson Nash <vtjnash+github@gmail.com>
N5N3 added a commit to N5N3/julia that referenced this issue Aug 31, 2022
N5N3 added a commit to N5N3/julia that referenced this issue Sep 1, 2022
The type `var` might be switched during intersection. Thus previous result looks order dependent.

When we intersect 2 `Vararg`s' length, we should always return the shorter one.
As we has consumed the extra elements in `intersect_tuple`.

Also fix JuliaLang#37257

Co-Authored-By: Jameson Nash <vtjnash+github@gmail.com>
N5N3 added a commit to N5N3/julia that referenced this issue Sep 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
types and dispatch Types, subtyping and method dispatch
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant