Make return type of map inferrable with heterogeneous arrays

[nalimilan]

Inference is not able to detect the element type automatically,
but we can do it manually since we know promote_typejoin is used for widening.
This is similar to the approach used for broadcast at #30485.

[vtjnash]

Seems like this should be part of the et computation at the top of the function (so that the total function here is more type-stable), no?

[nalimilan]

Actually I did the same for broadcast (see here) so that would make sense, even if that changes the return type in corner cases. I've just pushed a commit to do this.

[nalimilan]

I'm told FreeBSD failure is unrelated. Merging.

[KristofferC]

Backporting since it is a bit tangled up with #42172

[MrVPlusOne]

Hi,

I just noticed that the newly introduced type assertion in collect(::Generator) breaks my existing code. A minimal example:

map(enumerate(1:4)) do (i, _) 
    a = (x=i, y=(i==1 ? 1 : "a"))
    (a, 3)
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(itr::Base.Generator{Base.Iterators.Enumerate{UnitRange{Int64}}, Main.SEDL.var"#632#633"})
   @ Base /Applications/Julia-1.7.app/Contents/Resources/julia/share/julia/base/array.jl:734
 [2] map(f::Function, A::Base.Iterators.Enumerate{UnitRange{Int64}})
   @ Base ./abstractarray.jl:2878
 [3] top-level scope
   @ ~/.julia/dev/SEDL/scripts/hovercraft_example.jl:69
in expression starting at ...

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 somehow not compatible with the actual returned collection type.