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

map throws type assertion error #43112

Closed
MrVPlusOne opened this issue Nov 17, 2021 · 2 comments · Fixed by #43120
Closed

map throws type assertion error #43112

MrVPlusOne opened this issue Nov 17, 2021 · 2 comments · Fixed by #43120
Labels
regression Regression in behavior compared to a previous version
Milestone

Comments

@MrVPlusOne
Copy link

Hi,

(I'm opening this as a separate issue for easy tracking and to make sure people see this.)

I just noticed that the type inference related changes newly introduced in #42046 breaks my existing code. A minimal example:

map(1:4) do i
    a = (x=i, y=(i==1 ? 1 : "a"))
    b = 3
    (a, b)
end

throws the following error

ERROR: LoadError: TypeError: in typeassert, expected AbstractVector{<:Tuple{NamedTuple{(:x, :y), _A} where _A<:Tuple{Int64, Union{Int64, String}}, Int64}}, got a value of type Vector{Tuple{NamedTuple{(:x, :y)}, Int64}}
Stacktrace:
 [1] _collect(c::UnitRange{Int64}, itr::Base.Generator{UnitRange{Int64}, Main.SEDL.var"#636#637"}, #unused#::Base.EltypeUnknown, isz::Base.HasShape{1})
   @ Base ./array.jl:754
 [2] collect_similar(cont::UnitRange{Int64}, itr::Base.Generator{UnitRange{Int64}, Main.SEDL.var"#636#637"})
   @ Base ./array.jl:653
 [3] map(f::Function, A::UnitRange{Int64})
   @ Base ./abstractarray.jl:2849
 [4] top-level scope
   @ ~/.julia/dev/SEDL/scripts/hovercraft_example.jl:63

I just upgraded to 1.7.0-rc3 from rc1 this morning and immediately ran into this. Looks like the computed type annotation is more precise but is not compatible with the actual returned collection type.

@vtjnash vtjnash added the regression Regression in behavior compared to a previous version label Nov 17, 2021
@vtjnash vtjnash added this to the 1.7 milestone Nov 17, 2021
@nalimilan
Copy link
Member

nalimilan commented Nov 17, 2021

Indeed this has been introduced by #42046. This is due to promote_typejoin_union, which returns a too precise type for NamedTuple elements:

julia> Base.promote_typejoin_union(NamedTuple{(:x, :y), Tuple{Int64, Union{Int64, String}}})
NamedTuple{(:x, :y), Tuple{Int64, Union{Int64, String}}}

# But map and collect use rather
julia> Base.promote_typejoin(NamedTuple{(:x, :y), Tuple{Int64, Int64}}, NamedTuple{(:x, :y), Tuple{Int64, String}})
NamedTuple{(:x, :y)}

promote_typejoin_union should check recursively whether the passed type contains any Unions parameters, and if so call itself on them.

Here's another example to trigger the problem:

julia> itr = (((x=i, y=(i==1 ? 1 : "a")), 3) for (i, _) in enumerate(1:4))
Base.Generator{Base.Iterators.Enumerate{UnitRange{Int64}}, var"#8#9"}(var"#8#9"(), enumerate(1:4))

julia> Base.promote_typejoin_union(Core.Compiler.return_type(Base._iterator_upper_bound, Tuple{typeof(itr)}))
Tuple{NamedTuple{(:x, :y), _A} where _A<:Tuple{Int64, Union{Int64, String}}, Int64}

@nalimilan
Copy link
Member

I've made a first attempt at a fix at #43120. Unfortunately it's probably not correct, but let's hear what @vtjnash says.

@nalimilan nalimilan linked a pull request Nov 17, 2021 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
regression Regression in behavior compared to a previous version
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants