fix invalidations due to convert(Nothing, ::Any)

[simeonschaub]

Before this PR:

julia> using SnoopCompileCore

julia> struct A end

julia> @snoopr (::Type{<:A})(::AbstractVector) = 1
14-element Vector{Any}:
  MethodInstance for convert(::Type{Union{}}, ::AbstractArray)
 1
  MethodInstance for convert(::Type{Nothing}, ::Any)
 2
  MethodInstance for Union{}(::AbstractArray)
  "jl_method_table_insert"
  MethodInstance for Core.Compiler.convert(::Type{V} where V<:Core.Compiler.BitArray{1}, ::Vector{var"#s122"} where var"#s122"<:Union{Float32, Float64})
 1
  MethodInstance for Core.Compiler.convert(::Type{T}, ::Vector{var"#s122"} where var"#s122"<:Union{Float32, Float64}) where T<:(Vector{T} where T)
 1
  MethodInstance for Union{}(::Vector{var"#s122"} where var"#s122"<:Union{Float32, Float64})
  "jl_method_table_insert"
  (::Type{var"#s3"} where var"#s3"<:A)(::AbstractVector{T} where T) in Main at REPL[3]:1
  "jl_method_table_insert"

After:

julia> using SnoopCompileCore

julia> struct A end

julia> @snoopr (::Type{<:A})(::AbstractVector) = 1
Any[]

This was causing invalidations in StaticArrays.

[martinholters]

These two are equivalent, methods(convert) should only list one of them, in particular the latter as it has replaced the former. If you find that you need both to get the desired effect, something weird is going on.

[simeonschaub]

Ah yes, you are correct:

julia> methods(convert, Tuple{Type{Nothing}, Any})
# 2 methods for generic function "convert":
[1] convert(::Type{Nothing}, ::Nothing) in Base at some.jl:39
[2] convert(::Type{Nothing}, x::T) where T>:Nothing in Base at some.jl:38

I think I was just a bit confused because I previously assumed the definition in line 35 would just be equivalent to defining convert(::Type{Nothing}, ::Nothing), but that caused problems.

[simeonschaub]

@timholy Since this is my first foray into invalidation busting, would you mind taking a look whether this looks sensible to you?

[timholy]

Perfect.

This PR should fix this ambiguity:

julia> convert(Nothing, 3)
ERROR: MethodError: convert(::Type{Union{}}, ::Int64) is ambiguous. Candidates:
  convert(::Type{T}, x::Number) where T<:AbstractChar in Base at char.jl:179
  convert(::Type{T}, x::Number) where T<:Number in Base at number.jl:7
  convert(::Type{Union{}}, x) in Base at essentials.jl:203
  convert(::Type{T}, arg) where T<:VecElement in Base at baseext.jl:8
Possible fix, define
  convert(::Type{Union{}}, ::Number)
Stacktrace:
 [1] convert(#unused#::Type{Nothing}, x::Int64)
   @ Base ./some.jl:36
 [2] top-level scope
   @ REPL[4]:1

But I'm puzzled about why this isn't picked up by detect_ambiguities(Base).

[vtjnash]

Ambiguities are permitted (in the test) for Union{}

[simeonschaub]

This PR should fix this ambiguity:

Ah, cool! Didn't even realize that. >: constraints in method dispatch always confuse me a bit 😄

[simeonschaub]

@vtjnash I am sure this has been discussed at some point, but how much havoc would it cause to have a non-inclusive <:? It seems like most of the time, if you are dispatching on Type{<:...}, you don't actually want to include Type{Union{}}, but there is not really a good way to express this in the current type system.

[timholy]

xref #33780, #24179. Of course those still don't cover subset-but-not-equal as you need, but fixing #24179 would have to be done before this could even be attempted.

[timholy]

xref #38455 (comment)