Fix inference for splatting numbers. Fixes #22291

[timholy]

No description provided.

[martinholters]

It would be oh so nice if we could do constant propagation to the extent that abstract_iteration could figure out the constant length here, but until then this is probably OK. Assuming no-ones defines his own Number type which has other iteration properties, that is.

[Keno]

Assuming no-ones defines his own Number type which has other iteration properties, that is.

This is the problem though, because this would generate incorrect code in that case. We can't really have inference operate on the "let's hope nobody ever writes code like this" hypothesis.

[timholy]

If there's no better way to fix this, to be perfectly honest I could live with tt0 <: Union{Int, UInt}.

[timholy]

I guess another option would be to redefine number iterators so that the type system encodes the fact that they have length 1:

start(x::Number) = Val{false}()
next(x::Number, ::Val{false}) = (x, Val{true}())
done{s}(x::Number, ::Val{s}) = s

[vtjnash]

#18823 will also address / fix this

[timholy]

Given that there is a more general fix on the way, how about I add the tt0 <: Union{Int, UInt} as a hack for now? With #22210 I need it for indexing. (Changes in inlining ended up changing the inferred result; presumably we don't want that to happen, but that's where we are now.)

[martinholters]

Some more possible solutions that come to my mind:

• make numbers non-iterable? #7903
• Do this for tt0 <: Number and change jl_f__apply to effectively not splat Numbers. But having splatting subtly different from iteration may be a bit too surprising.
• Do this for tt0 <: Number provided that the methods that would be called for start, next, and done for tt0 are the ones that are defined in Base for Number.

[JeffBezanson]

There is some precedent for inference using a corenumtype union to restrict optimizations to known types.

[timholy]

This passed tests, so barring objections I'll merge soon. Hmm, fixing the inference didn't fix all the performance problems. Would be good to pursue this further, but in #22210 I took the pragmatic route and just worked around it. I think there's no immediate pressure to merge this, so I will just let this sit until someone else feels the need.