remove string("a", 'b') regression. This shouldn't work

[oscardssmith]

Fixes #50458, #49249 but I have no idea why.
Before:

@btime string("a", 'b')
  246.945 ns (6 allocations: 184 bytes)

After:

@btime string("a", 'b')
18.195 ns (1 allocation: 24 bytes)

Can anyone explain this? It feels like a compiler bug to me.

[Seelengrab]

Just a guess, but this reads like removing the type annotation leads to better specialization due to the Vararg possibly getting a narrower type?

[nsajko]

Pretty sure this is expected behavior, see: https://docs.julialang.org/en/v1/manual/performance-tips/#Be-aware-of-when-Julia-avoids-specializing

As a heuristic, Julia avoids automatically specializing on argument type parameters in three specific cases: Type, Function, and Vararg.

[Seelengrab]

But then the change here ought to not make a difference 🤔

[nsajko]

It's weird though, if I define a function like h(z::Vararg{Union{Int8, Int16, Int32, Int64}}) = +(z...) (a four member union, just like before this PR), the specialization happens fine judging by @code_warntype h(one(Int8), one(Int16)).

[Seelengrab]

@code_warntype is lying to you, as is mentioned just a few lines below the line you linked:

Note that @code_typed and friends will always show you specialized code, even if Julia would not normally specialize that method call. You need to check the method internals if you want to see whether specializations are generated when argument types are changed, i.e., if (@which f(...)).specializations contains specializations for the argument in question.

[KristofferC]

Should probably tweak the commit message. There should be a chance to understand the change by reading just the commit message.

[JeffBezanson]

@vtjnash Shouldn't we root-cause this? Seems like a bad bug somewhere. This function doesn't even have multiple methods.

[gbaraldi]

I'll try and see if it's at least bisectable, not the regression here but the weird behaviour we are seeing.

[oscardssmith]

#50929 replaces this (assuming it's backportable)