fix new type instability from getindex(::String, r::UnitRange{Int})

[aviatesk]

After investigating the cause of the invalidation reported in #55583, it was found that the issue arises only when r is propagated as an extended lattice element, such as PartialStruct(UnitRange{Int}, ...), for the method of getindex(::String, r::UnitRange{Int}). Specifically, the path at

julia/base/compiler/typeinfer.jl

Lines 809 to 815 in cebfd7b

	if uncached
	# our attempt to speculate into a constant call lead to an undesired self-cycle
	# that cannot be converged: poison our call-stack (up to the discovered duplicate frame)
	# with the limited flag and abort (set return type to Any) now
	poison_callstack!(parent, frame)
	return true
	end

is hit, so the direct cause was the recursion limit for constant inference (inference with extended lattice elements, more correctly).

To explain in more detail, within the slow path of nextind which is called inside getindex(::String, ::UnitRange{Int}), the 1-argument @assert is used

julia/base/strings/string.jl

Line 211 in cebfd7b

@assert l >= 0xc0

. The code related to print associated with this @assert further uses getindex(::String, ::UnitRange{Int}), causing the recursion limit. This recursion limit is only for constant inference, which is why we saw this regression only for the PartialStruct case. Moreover, since this recursion limit occurs within the @assert-related code, this issue did not arise until now (i.e. until #49260 was merged).

As a solution, I considered improving the recursion limit itself, but decided that keeping the current code for the recursion limit of constant inference is safer. Ideally, this should be addressed on the compiler side, but there is certainly deep recursion in this case. As an easier solution, this commit resolves the issue by changing the 1-arg @assert to the 2-arg version.

• replaces fix a huge part of invalidation on defining a new Integer subtype #55583

[aviatesk]

We can add this regression test:

let m = only(methods(Base._string_n, (Integer,)))
    mi = Core.Compiler.specialize_method(m, Tuple{typeof(Base._string_n),Integer}, Core.svec())
    m′ = only(methods(Base.getindex, (String,UnitRange{Int})))
    mi′ = Core.Compiler.specialize_method(m′, Tuple{typeof(Base.getindex),String,UnitRange{Int}}, Core.svec())
    @test mi′ ∉ mi.backedges
end

but I have doubts about whether it will remain a robust test case in the future. It's probably safer to use tools like JET for testing this sort of things.

[nsajko]

In my PR this reproducer is provided:

using SnoopCompileCore
length(@snoop_invalidations begin
    struct I <: Integer end
    Csize_t
    Csize_t(::I) = Csize_t(0)
end)

Is there a way to count invalidations that could be used from within the test suite? Could we add a test something like:

@test length(invalidations) < 50

?

[aviatesk]

The number of invalidations isn't that robust and SnoopCompile isn't available for Julia base test suite at this moment.