-
-
Notifications
You must be signed in to change notification settings - Fork 5.4k
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
suboptimal return type inference for Base.setindex
#54462
Labels
compiler:inference
Type inference
Comments
nsajko
added a commit
to nsajko/julia
that referenced
this issue
May 14, 2024
nsajko
added a commit
to nsajko/julia
that referenced
this issue
May 15, 2024
FTR, this PR is part of a series of changes which (re)implement many of the operations on tuples using a new recursive technique. The ultimate goal is to hopefully increase the value of the loop-vs-recurse cutoff (`Any32`, sometimes hardcoded `32`) for tuple operations. Updates JuliaLang#54462 Closes JuliaLang#54463 Example type inference improvement: ```julia-repl julia> Core.Compiler.return_type(Base.setindex, Tuple{Tuple{Vararg{Int}},Int,Int}) Tuple{Vararg{Int64}} ```
This was referenced May 15, 2024
julia> methods(ntuple, Tuple{Any,Val})
# 5 methods for generic function "ntuple" from Base:
[1] ntuple(f, ::Val{3})
@ ntuple.jl:50
[2] ntuple(f, ::Val{2})
@ ntuple.jl:49
[3] ntuple(f, ::Val{1})
@ ntuple.jl:48
[4] ntuple(f, ::Val{0})
@ ntuple.jl:47
[5] ntuple(f::F, ::Val{N}) where {F, N}
@ ntuple.jl:69 Five methods is too much for inference which therefore bails out. Which is quite unfortunate. Maybe it's worth renaming those to |
#54528 is an alternative to that |
👍 Yes, that looks like good idea to me. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
FWIW the type inference for
Base.setindex
was better on v1.7.3.A quick fix, for
Base.setindex
at least, is adding a::Tuple
type assertion for theBase._setindex
return value.However, I'm not sure why does the inference fail, actually? We do have:
Cthulhu.descend
shows that, inBase._setindex
, the return value gets inferred asAny
even though theVal{N}()
gets inferred asVal
. Weird.The text was updated successfully, but these errors were encountered: