Rename dispatchtuple to indivisible_type

[topolarity]

This is hopefully a more intuitive (type-semantic) notion of what a "dispatch tuple" is.

Ideally, it makes two key properties more obvious:

1. indivisible types are either type-equal or disjoint with each other (T == U or T != U) - they are never partially overlapping
2. these signatures are always compilable since they are "maximally specific"

This new definition should be mostly equivalent to the existing one for Tuples, and it extends the predicate to be be analogously defined over other DataTypes (e.g. Int / Vector{Any}, which are also indivisible)

[vtjnash]

This new definition point 1 might be somewhat contentious as it defines that forming Tuple{Union{}} is invalid, which is currently true, but contentious. We also are not allowed to remove public APIs. The point 2 is also not quite true either, since we have a class of malformed types that get mistakenly used in dispatch, such as Tuple{Type{Vector.body}}}, which is currently a known class of dispatch bugs and crashes.

[vtjnash]

(fwiw, the original name for this function was isleaftype, and it was changed to isdispatchtuple when the definition of it was last changed)

[topolarity]

This new definition point 1 might be somewhat contentious as it defines that forming Tuple{Union{}} is invalid

I think the main refinement required is to define "indivisible" as T′ <: T implies T′ == T for all inhabited T′ (the definition is already wrong for Union{} for the same reason - thanks for pointing that out)

We also are not allowed to remove public APIs

Good point, although why this was ever a public API without a clear semantic definition is unclear to me - will add that back

The point 2 is also not quite true either, since we have a class of malformed types that get mistakenly used in dispatch, such as Tuple{Type{Vector.body}}}, which is currently a known class of dispatch bugs and crashes.

I don't think that situation is affected by this PR - malformed types seem like a separate issue

[vtjnash]

I don't think that situation is affected by this PR - malformed types seem like a separate issue

It means that point 2 will never be achievable, so it should not be part of the definition

[topolarity]

It means that point 2 will never be achievable, so it should not be part of the definition

Sure. It's not intended to be part of the definition, just a corollary really

I only included it because I was trying to motivate this fast-path:

julia/src/gf.c

Line 3135 in 35bfba9

int is_compileable = ((jl_datatype_t*)ti)->isdispatchtuple;

[topolarity]

These tests fail on master w/o this PR, which I assume is a bug:

@test Base.isdispatchtuple(Tuple{Tuple{Type{Union{Int,Float64}}}})
@test !Base.isdispatchtuple(Tuple{Tuple{DataType}})

[vtjnash]

Those both return correct answers for me on master. What are you seeing:

julia> Base.isdispatchtuple(Tuple{Tuple{Type{Union{Int,Float64}}}})
false

julia> Base.isdispatchtuple(Tuple{Tuple{DataType}})
true

[topolarity]

Tuple{Tuple{DataType}} has a strict subtype (Tuple{Tuple{Type{Int}}}) that could appear in a call, making it not a dispatch tuple

Tuple{Tuple{Type{Union{Int,Float64}}}} has no such sub-types just like Tuple{Type{Union{Int,Float64}}} has none

[vtjnash]

Tuple{Type{Int}} is not a constructible object, so cannot appear in a call

[topolarity]

Oh wow, that's... surprising. I didn't know that.

Anyway I think the definitions still coincide (Tuple{Type{Int}} is not inhabited so it does not affect divisibility either), so I'll update the computation to match

[vtjnash]

Sounds good. I don't think our current definition is likely to remain valid for much longer (particularly the part about no subtypes or supertypes) so it is helpful to try to think about that we might replace it with. Probably at least helpful to clarify that "appear in call" means the same as "has_concrete_subtype"

[topolarity]

That does seem fatal actually...

This means that we have to refer to dispatch in this definition, since inhabited dispatch tuples != inhabited tuples (they are a strict super-set)