fix #40814, fix type inference regression introduced in #40379

[aviatesk]

Fixes the inference regression, while retaining the cases addressed by
#40379.

The same Type-name comparison pass (i.e. a branch of isa(c, DataType) && t.name === c.name)
can lead to more accurate result by recursive comparison than isType
check pass (i.e. a branch of isType(t)), and preferring the former
over the latter fixes the regression.

But just swapping the branch will lead to #40336,
and so this PR also implements additional check to make sure type_more_complex
still detects a single-level nesting correctly (especially, the tt === c parts).

[aviatesk]

@nanosoldier runbenchmarks(ALL, vs = ":master")

[nanosoldier]

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. cc @christopher-dG

[aviatesk]

The benchmark results look okay to me.

[vtjnash]

This appears to get the check exactly backwards: while the test in this function is supposed to find a reason that the recursion is safe, this instead looks if the recursion matches a known reason it is unsafe. As such, this would seem to be neither total nor transitive.

[aviatesk]

while the test in this function is supposed to find a reason that the recursion is safe, this instead looks if the recursion matches a known reason it is unsafe. As such, this would seem to be neither total nor transitive.

Hmm, I'm not quite sure what you mean by this. Why should inference always be conservative when seeing Type in a recursion ?

The comment of limit_type_size says:

julia/base/compiler/typelimits.jl

Lines 15 to 18 in 8535b8c

	# limit the complexity of type `t` to be simpler than the comparison type `compare`
	# no new values may be introduced, so the parameter `source` encodes the set of all values already present
	# the outermost tuple type is permitted to have up to `allowed_tuplelen` parameters
	function limit_type_size(@nospecialize(t), @nospecialize(compare), @nospecialize(source), allowed_tupledepth::Int, allowed_tuplelen::Int)

and I'm not sure why we should give up the comparison pass (i.e. elseif isa(c, DataType) && t.name === c.name) when isType(t).
Even if we go with the comparison pass first, eventually a single-level complexity difference (e.g. Type{Type{Int}} vs. Type{Int} will be caught by newly introduced check tt === c and more level complexity difference will be caught by isType(tt) as before.
Maybe you mean the tt === c part is too ad-hoc to be safe in all the possible cases ?

[vtjnash]

We could delete the case for Type entirely, but we cannot move it without re-introducing the previous bug that PR fixed. The question is mainly which rule we like better. The implementation of _totuple currently uses the tuple_type_tail function, which we probably should deprecate, as it is causing _totuple to make inaccurate subtyping claims. I haven't yet been able to find a better formulation however, so we might need better compiler support first for Core._apply.