Formatting difficulties with clang-format

[bam241]

I have the OpenMC formatting hook installed as well as clang-format.

Files were properly formatted (according to my clang-format), but CI was still complaining.

I think it is a version problem, (wasn't able to install clang-format15 as used in CI), I have clang-format 17.0.3 installed on my Mac and no easy way to install clang-format15 (and Brew doesn't offer it to me :( ) I had to manually guess how to modify my files to get CI happy.

if this is a clang-format version issue, I think one should to state the version followed by openMC. Also maybe having the suggested format of the files in the CI artefacts could be useful ? (not fully convinced there because it would require some digging by user.)

The point here was just to raise the issue I faced, my local clang-format with the git hook not complaining and CI syntax checker complaining and the only information available was file and line with the issue in the detail of the syntax job.

[shimwell]

Perhaps we could add a pre-commit like this example https://github.com/shimwell/openmc/blob/adding_precommit/.pre-commit-config.yaml

[pshriwise]

I agree this process could be more transparent. I'm you had to do so much digging to get it sorted out @bam241! I agree that at a minimum we should post the clang-format version to be used in the PR template and in the developer's guide. I'll submit a PR for that shortly.

I like the idea of producing an artifact in the CI run. A diff file would be ideal IMO. Then even if you aren't using the right version of clang-format (or don't have it at all), you can still pull that artifact and apply it as a patch.

I like the idea of applying these in an automated fashion, but if we go that route I'd like it to be something we trigger on the PR separate from the CI check (a bot perhaps). My concern with doing it automatically for each commit is forcing new contributors to pull those changes when they're making updates in their local branch to address review comments and adding to our already-high barrier for contribution.

[pshriwise]

Also, it'd probably be good for us to figure out why different versions are an issue if possible.

[bam241]

@pshriwise so efficient!

let me know if you wish me to keep this open for note keeping about the artifact/automation or if you wish me to close it.