ci: update clang-format version about gtensor

[bd4]

12 seems like the right version - it's the highest version available in old lts, 20.04, so anyone using an old docker image can still get it easily.

[germasch]

Well, it'd be nice first of all if different versions of clang-format would do formatting consistently, which I guess is not always the case :(

I haven't looked into any of this in detail -- if I work on crusher, I end up with a mis-formatted bit, and I guess that's from
Cray clang-format version 14.0.2.

The ideal thing would be to find some way to change the config such that it doesn't matter whether it's clang-format 14, or 9, or somewhere in between. Not sure that's possible. This is the diff I've been getting:

--- ./tests/test_gtensor.cxx	(original)
+++ ./tests/test_gtensor.cxx	(reformatted)
@@ -775,[10](https://github.com/wdmapp/gtensor/actions/runs/3865193086/jobs/6588531541#step:4:11) +775,7 @@
   auto k_a = a.to_kernel();
   auto k_b = b.to_kernel();
 
-  auto lf = GT_LAMBDA(int i) mutable
-  {
-    k_b(i) = k_a(i);
-  };
+  auto lf = GT_LAMBDA(int i) mutable { k_b(i) = k_a(i); };
 
   gtLaunchKernel(kernel_test_lambda, 1, 3, 0, 0, b.shape(), lf);
 }```

I guess otherwise I'll agree that 12 seems like a reasonable choice, but I actually don't know if it behaves more like 9, or like Cray-14, or yet differently..

[bd4]

The problem appears to be that newer versions of clang-format don't recognize GT_LAMBDA(...) ... as a lambda. Even setting AllowShortLambdasOnASingleLine: All in the config does not change and it wants to expand it. Not obvious to me how to work around this.

[bd4]

clang 14 is where this changed, and it is still that way in 15, so does not seem like it will change.

The 🙈 solution, is to update CI to 12, and use https://github.com/muttleyxd/clang-tools-static-binaries binaries to get it on machines that have newer versions and it's not easy to install 13 or earlier. Of course using binaries from a github repo, is not so nice (a github action that uses it in a docker container on microsoft infrastructure is different)... but on the other hand we trust github repos a lot and built from source without making sure the code has been audited 🙃 .

[bd4]

btw, the clang-format on crusher at /usr/bin is 9, so you can use that, probably by adjusting path order. Edit: never mind, that was actually a version I installed myself in my bin dir, not in /usr/bin :P.

[bd4]

A "safer" way to get clang-format 9-13 on crusher, is copy it from your local linux installed via verified packages.

[bd4]

Perhaps a better solution:

-AllowShortFunctionsOnASingleLine: Inline
+AllowShortFunctionsOnASingleLine: All

This changes the formatting on a lot of files, but it results in the GT_LAMBDA staying on one line and v-9 and v-14 are the same. Strangely, it makes a lot of inline function to single line that weren't before, so that seems like a bug to me. Like the auto keyword is throwing it off.

[germasch]

👍