Fix Tuple inference regression from #18467

[TotalVerb]

This fixes the cat regressions from #18467 (seen in #18569) on my machine. Haven't tested the other ones yet, but I suspect they will be similar. Could someone run nanosoldier?

I wasn't able to come up with a shorter test. I can remove the current one if it's a bad thing to test internal functions.

cc @tkelman @KristofferC @Sacha0

[tkelman]

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

[TotalVerb]

I've run the sort benchmarks locally and have found no change with this fix. It's possible that I screwed up the testing; we should wait for Nanosoldier. But it's possible that #18467 introduced regressions that are not fixed here, or that a different PR introduced those regressions.

[KristofferC]

Could run a benchmark on a revert commit.

[TotalVerb]

How do we do that? @KristofferC Should I make an alternative PR reverting #18467?

[TotalVerb]

I can run benchmarks locally, but it might take a while.

[KristofferC]

Just make a branch and call nanosoldier in the comment section of the commit. No need for a PR.

[TotalVerb]

@KristofferC I don't think I can call nanosoldier. Could you call nanosoldier here? TotalVerb@ea69c12

[KristofferC]

Has to be on the JuliaLang one I believe. I go to bed now but I can do it tomorrow if no one does it before me.

[TotalVerb]

I've run the benchmarks locally for the commit before the revert commit, and I'm currently running them on the revert commit. This should shed some insight as to whether #18467 was the cause.

[nanosoldier]

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

[TotalVerb]

Nanosoldier seems to indicate that the cat benchmark was the only benchmark that changed (I'm treating everything else as noise). So the remaining possibilities are:

• Work around inference bug with Vararg #18467 introduced other regressions that this PR does not fix.
• The other regressions are not caused by Work around inference bug with Vararg #18467.

I will be able to make a more informed guess which of these is true after the benchmarks complete locally. It is rather unfortunate (unlucky?) that the first benchmark I decided to test with was the cat one.

[TotalVerb]

Perhaps it's worth getting nanosoldier to check, but local benchmarking has found that the only memory regression due to #18467 over 1% is ["array","cat",("catnd",5)], which is indeed fixed by this PR.

This means that the large number of other regressions in #18569 are likely caused by a different commit. @tkelman @Sacha0

[TotalVerb]

Is this good to merge?