Fix nightly CI tests

[Liozou]

This (hopefully) turns the angry red cross into a nice green tick.

There are two separate commits, with two distinct goals:

• the first commit is a genuine test fix for julia versions >= v1.6, which reflects RFC: print all types using equivalent exported aliases JuliaLang/julia#36107
• the second commit is not a fix, it just marks as @test_broken what has been broken for a few months now on julia versions >= v1.5. I tried to correctly fix this issue but @code_typed mul!(c,A,b) yields the same thing on v1.4 and v1.5 while @code_llvm mul!(c,A,b) is different, so I have no idea how to fix it, sorry.

(The second commit is in direct conflict with 6e0936f so #783 will have to remove that commit if this PR gets merged.)

EDIT: added a third commit, see #810 (comment)

[fredrikekre]

Probably need to adjust for JuliaLang/julia#37085 too, let's rerun the tests.

[mateuszbaran]

Apparently the tests are still passing. I don't understand it now, that PR to Julia was supposed to add spaces after commas but it doesn't everywhere?

[mateuszbaran]

That's probably because show_typealias doesn't add spaces after commas.

[mateuszbaran]

JuliaLang/julia#37302 broke a test again (but all that is needed to fix it is adding one space). Do we want to fix this in this PR or a separate one?

[Liozou]

I fixed the whitespace issue from JuliaLang/julia#37302 and while I was at it I also marked as test_broken the ambiguity test for julia >= v1.6 because of the very recent JuliaLang/julia#36962.
Tested against master, detect_ambiguities(StaticArrays) now yields 45 method ambiguities, while detect_ambiguities(LinearAlgebra, StaticArrays) yields 114 method ambiguities and takes almost 10 minutes to run on my computer (with a decent CPU). But that's a separate issue from that which is fixed by this PR.

[mateuszbaran]

Thanks, I think we can merge this. 114 ambiguities is quite a lot, I'll check what they are.

[Liozou]

Some of them are internal LinearAlgebra ambiguities, for instance the first I get is

(ldiv!(transA::Transpose{var"#s851", var"#s850"} where var"#s850"<:(LU{var"#s849", var"#s848"} where var"#s848"<:(StridedMatrix{T} where T) where var"#s849") where var"#s851", B::StridedVecOrMat{T} where T) in LinearAlgebra at julia/stdlib/v1.6/LinearAlgebra/src/lu.jl:402, ldiv!(transA::Transpose{var"#s820", var"#s819"} where var"#s819"<:(UpperTriangular{T, var"#s818"} where var"#s818"<:(StridedMatrix{T} where T)) where var"#s820", B::StridedVecOrMat{T}) where T<:Union{Float32, Float64, ComplexF32, ComplexF64} in LinearAlgebra at julia/stdlib/v1.6/LinearAlgebra/src/triangular.jl:769)

which has nothing to do with StaticArrays. But some of them might be genuine, I'm afraid I don't have the time to look into this precisely at the moment.

[Liozou]

CI is green at least!

[c42f]

yields 114 method ambiguities and takes almost 10 minutes to run on my computer (with a decent CPU).
...
which has nothing to do with StaticArrays

Oh dear, the large runtime is a disappointing regression in usability for detect_ambiguities :-(

I guess we could follow the style of the test in https://github.com/JuliaLang/julia/pull/36962/files#diff-cd2de97b330251a95f7a2b119e9daf48

According to JuliaLang/julia#36962 (comment) the new ambiguities in Base were due to JuliaLang/julia#36951, so in the sense that it's a bug in Base, I think marking as @test_broken is fine until 1.6 is out.

Let me push a small refinement to this PR so that we don't forget to look back at this when 1.6 comes out.

[Liozou]

Bump. Any reason to postpone this?

[c42f]

No, I just forgot to come back and merge it!