Eliding boundschecks does not work with vararg function

[jakobnissen]

Discovered by matthias314 in this discourse thread

julia> @inline function f(x...)
           @boundscheck println("checking bounds")
           return 0
       end
f (generic function with 1 method)

julia> g(x...) = @inbounds f(x...)
g (generic function with 1 method)

julia> g(1, 1)
checking bounds
0

Annoyingly, code introspection gives incorrect results, presumably due to #32834. Maybe the issue is that it doesn't actually inline?

[matthias314]

Calling g(1) instead of g(1,1) works fine (no bounds check). However, once g(1,1) has been called, the behavior of g(1) sometimes changes in that all further calls to g(1) suddenly involve a bounds check. At other times, the behavior of g(1) remains unchanged after calling g(1,1). I don't know what triggers this difference.

[vtjnash]

This is because we will happily use a cached method if it applies, if even it isn't the best possible match we could have generated, as that is the point of a cache.

julia> typeof(g).name.mt.cache.sig
Tuple{typeof(g), Int64, Vararg{Int64}}

And the optimization inliner is not smart enough to realize it can rewrite the call to f

julia> code_typed(g, (Int, Vararg{Int}))
1-element Vector{Any}:
 CodeInfo(
    @ REPL[2]:1 within `g`
1 ─ %1 = Core._apply_iterate(Base.iterate, Main.f, x)::Int64
└──      return %1
) => Int64

by constructing the arg list for inlining with tuple, head, and tail

%1 = Core._apply_iterate(Base.iterate, tuple, x)::Tuple{Vararg{Int64}} # this is can be later removed as it is simply the identity function
%2 = InliningTodo(f, with f=f, x=%1)

perhaps we should make a new new :invoke_varargs Expr type, which bypasses the construction of the tuple for the trailing arguments.