Use Base.promote instead of promote_tuple_eltype to fik promotion

[andreasnoack]

...issue for element types defined after StaticArrays.

Currently, we have this behavior

julia> struct MyFloat64 <: Real
         x::Float64
       end

julia> Base.promote_rule(::Type{Float64}, ::Type{MyFloat64}) = MyFloat64

julia> SArray{Tuple{2}}((2.0, MyFloat64(1.0)))
2-element SArray{Tuple{2},Real,1,2} with indices SOneTo(2):
           2.0
 MyFloat64(1.0)

probably because the generated function promote_tuple_eltype can't handle types defined later than itself. With this PR, the example gives

julia> SArray{Tuple{2}}((2.0, MyFloat64(1.0)))
2-element SArray{Tuple{2},MyFloat64,1,2} with indices SOneTo(2):
 MyFloat64(2.0)
 MyFloat64(1.0)

The PR generally reduces the number of generated functions.

A remaining issue is

StaticArrays.jl/test/SHermitianCompact.jl

Line 228 in 4cfeb58

@test adjoint(SHermitianCompact{3}(a)) == adjoint(a)

because there is no promote_rule between the matrix valued elements. @tkoolen Any thoughts on the better way to fix this case?

[andyferris]

Cool. Did you look into performance of promote(x...)?

Interesting corner cases to consider include Union element types, or longer tuples, or both. Certainly we wouldn't want generated code to regress for things like SVector((x::Float64, y::Float64, 0::Int)) on any of the Julia 1.0, 1.1, 1.2, or 1.3 series compilers.

[andyferris]

probably because the generated function promote_tuple_eltype can't handle types defined later than itself.

This is confusing, right? The function generator doesn't currently call promote_type at all... it generates code that can call the latest version by simply expanding out the tuple's type parameters. Does anyone understand what might be going on there?

[c42f]

@andyferris ah hah; here's where we call promote_tuple_eltype from within a generated function — looking through this PR I think we'd only need to change this one line (by removing the $ character :-) ) to fix the original problem. Is that right @andreasnoack?

Regardless of that it's always nice to remove some generated functions so I'm generally positive about doing these changes as a cleanup. Provided the original reason for needing promote_tuple_eltype is gone.

[andreasnoack]

Just tried it and it doesn't seem to be sufficient to fix the issue.

[c42f]

That's weird, I was sure this would fix it. Locally removing the $ seems to work for me:

julia> struct MyFloat64 <: Real
                x::Float64
              end

julia> Base.promote_rule(::Type{Float64}, ::Type{MyFloat64}) = MyFloat64

julia> SArray{Tuple{2}}((2.0, MyFloat64(1.0)))
2-element SArray{Tuple{2},MyFloat64,1,2} with indices SOneTo(2):
 MyFloat64(2.0)
 MyFloat64(1.0)

(btw beware that you can't always rely on Revise to work with this stuff... changes may require restarting Julia and reloading StaticArrays)

[andyferris]

Good catch, @c42f.

I guess if we just change this one line, then it should unambiguously have no negative impact on generated code. If we merge the whole PR we should probably also stress test this with long Union-type static arrays, etc, first.

[andreasnoack]

Not sure what went wrong but indeed it seems to be sufficient to fix the issue. I've opened #671. I still think we should consider geetting rid of the generated function here but it's not urgent.

[andreasnoack]

Cool. Did you look into performance of promote(x...)?

I did some timings and didn't see any regressions but timing StaticArrays code is always a bit tricky. I guess the most important thing is that I didn't see any new allocations. I assumed that the old issue that made you promote_tuple_eltype would show up as @inferred failures. Is that correct?

[coveralls]

Coverage decreased (-0.4%) to 81.158% when pulling c72f42f on an/promote into 4cfeb58 on master.

[c42f]

Doing some archeology, the origin of promote_tuple_eltype was in the very first StaticArrays code commit cef8abc (under then name promote_eltype). That might even have been prior to julia 0.5 so it seems very likely we don't need this hack anymore. But I also don't know exactly what caused Andy to put it in...

[andyferris]

lol, nice archaeology. Constructors were done first - promotion behaving like other arrays obviously being pretty important. How time flies :)

[andyferris]

In any case we should double check some generated (native) code first but in general I am in favour of removing generated code.