.clang-format file compatible with clang-format 18

[leekillough]

On Ubuntu 24.04 LTS, the default clang-format version is 18.

This PR is draft and advisory. I suggest you consider something like it, to make the .clang-format file compatible with more versions.

I use this .clang-format on my Ubuntu 24.04 LTS machine, since installing clang-format 20 may require installing other Clang/LLVM binaries which will mess up the whole Clang/LLVM tree, and lead to a "discordant" installation, where a mixture of different versions of different tools may fail to interact correctly.

It's unfortunate that clang-format does not allow a version specifier in the .clang-format file, so that it behaves according to a certain clang-format version, and requires a clang-format of that version or later. If only they learned from, say, Perl, where you can use v1.2.3; to specify a specific version.

@berquist @feldergast @gvoskuilen

[github-actions]

CLANG-FORMAT TEST - FAILED (on last commit):
Run > ./scripts/clang-format-test.sh using clang-format v20 to check formatting

[berquist]

I can't comment on the specific changes in the .clang-format file itself, but some notes about infrastructure:

• One possible solution is to have a .clang-format-18 file and then set up your (local) tooling to explicitly use this configuration. It probably should not go in this repository directly, since it may be confusing for others, and there is the perceived burden of maintaining the two files. Keeping it local is arguably safe, since the production .clang-format almost never changes.
• Much of this pain could be avoided if those tool versions specified in pre-commit propagated outward, but by current design this isn't possible, so it's annoying for those of us who want to run the tools in the editor. The long-term solution would be to use Nix or Spack to always provide the blessed versions of these specific tools where there is not a range of compatibility, but that is a big lift.

In the meantime, I symlink newer versions of LLVM binaries selectively into a folder that's on my PATH when I'm working in the SST tree.

[feldergast]

I have a .clang-format file that gave essentially the same results for v18 and v20, but never found the time to do final testing on it. Let me compare that file to what you have here. If we can find one that generally works for both, then I don’t have an issue with updating the file. However, we won’t be testing it against both versions, so will only officially support v20.

As far as getting clang-format20, my experience with clang-format has been that it’s entirely independent of the rest of the clang suite if you can get it in binary form. You can simply copy the binary into your path without needing any of the rest of the binaries. Though finding the binaries pre-compiled for specific OS versions can sometimes be tricky.

[leekillough]

I can't comment on the specific changes in the .clang-format file itself, but some notes about infrastructure:

* One possible solution is to have a `.clang-format-18` file and then set up your (local) tooling to explicitly use this configuration.  It probably should not go in this repository directly, since it may be confusing for others, and there is the perceived burden of maintaining the two files.  Keeping it local is arguably safe, since the production `.clang-format` almost never changes.

Every time I start with a clean sst-core tree, I copy my ~/.clang-format file to sst-core/, and every time I use git status, I see:

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   .clang-format

So I very used to using this .clang-format modified for compatibility with clang-format 18. I've been using it for months, ever since the clang-format 20 requirement was imposed.

It's a minor nuisance to have to use an altered .clang-format file, but it's less risky than installing clang-format 20, which may cause discordant Clang/LLVM binaries to be installed. I suppose I could build clang-format with a different --prefix, but then so many dependencies will have to be built and installed there too. This workaround, to make .clang-format compatible with clang-format version 18, is much simpler to do.

[jmlapre]

Can't we use GitHub Actions and remove the .clang-format file entirely? I found two; there are likely more:

• https://github.com/marketplace/actions/clang-format-check
• https://github.com/marketplace/actions/clang-format-lint

[leekillough]

Can't we use GitHub Actions and remove the .clang-format file entirely? I found two; there are likely more:

* https://github.com/marketplace/actions/clang-format-check

* https://github.com/marketplace/actions/clang-format-lint

The formatting is controlled by the first .clang-format file in the same or parent directory from the file being tested, and those Actions use the .clang-format file to determine the project's coding style. We have one at the top-level directory.

Actions will not substitute for running clang-format locally, such as from the command-line or from within emacs (M-x clang-format). I'm sure it can also be integrated into VSCode and Vim.