OK, well whoops. The new clever check which detects C++ files changed and only runs Clang Format on the changed files, seems to have goofed. There's obviously nothing wrong with my C++ changes in this branch.......since there aren't any. And if I had some changed, it would have worked fine. Fun!

When I locally run the code that we have on GHA to detect any C++ ish files changing:

$ changed_files=$(git diff --name-only HEAD^ HEAD src/ tst/ | /bin/grep -E '\.(cpp|cc|c|hpp|hh|h)$')
$ echo $changed_files 

$ file_count=$(echo "$changed_files" | wc -l)
$ echo $file_count 
1

$changed_files seems to have a new line in it, meaning wc -l will count it as a line. Not sure why yet.

⚠️ Regressions detected on macos-14 for commit 5350435

• View Results
• Download Regressions

So the question is, do I click merge on this and get regressions gone from everyone's branch? Or do we try to fix it here really quick and get this merged as a real fix. I'm not able to pivot to it today. @JasonGlazer is this like a one- or two-liner fix? Or will it need some more logic added in?

I think the fix to #11087 is probably just a few lines but that is an assumption. I haven't looked at the offending code. I'm ok with merging this and fixing the underlying issue later.

OK, good. Merging this in now. It should be easy enough for someone to reproduce the issue by undoing my IDF comments in this PR in two branches, building both, and then running regressions on those three offending files. It should trigger table size errors, which are now reflected in the table big diff count. Then fixing the tabular output code to produce unique table names. Thus I would expect the actual fixing PR to include:

• undoing the comments I've made in these 3 IDFs
• some tabular output code changes
• perhaps additional unit testing

Alright, merging this. Thanks.

Maybe also add a new CI test to check for uniqueness in table names.