Jeff, all,
I am looking into uncrustify [1], which is highly configurable and has
the ability to ignore many of its >700 rules available. Some of the
ignored rules seem broken, for which I have filed a bug already [2].
Right now it seems that there is no way to ignore the indentation of
continued statements, meaning that it will always apply some indentation
rule to continuing lines [3]. Since we don't have rules for continued
statements I want to get uncrustify to just ignore them (I'm sure we
have plenty of different formattings there). This might require a patch
eventually.
There may be other things such as the yoda comparisons which are not yet
available but could probably be added.
Overall, I think it can do what we want: enable a small number of rules
and let us know whether it would change any formatting on a given file,
which we can use in CI to test for compliance. The Score-P project has
done that in the past (not sure what the status is right now).
The project seems actively maintained and receptive to issues and
feature requests. I will continue looking into it, although it might
take some time. If anyone has some cycles (or a student) to spare we
might get it to where we want it fairly quickly.
Cheers
Joseph
[1] https://github.com/uncrustify/uncrustify
[2] https://github.com/uncrustify/uncrustify/issues/3173
[3] https://github.com/uncrustify/uncrustify/issues/3174
On 5/17/21 9:59 PM, Jeff Squyres (jsquyres) via devel wrote:
FYI: It was decided last week that we will abandon the current effort to
reformat master / v5.0.x according to style rules.
SHORT VERSION
We have already reformatted opal/ and tests/. But the two PRs for reformatting
ompi/ brought up a whole bunch of issues that do not seem resolvable via
clang-format. As such, we're just walking away: we're not going to revert the
reformatting that was done to opal/ and tests/ on master and v5.0.x, but we're
just going to close the ompi/ reformatting PRs without merging.
Many thanks to Nathan who invested a lot of time in this; I'm sorry it didn't
fully work out. :-(
MORE DETAIL
It turns out that clang-format actually parses the C code into internal language primitives and
then re-renders the code according to all the style choices that you configure. Meaning: you
have to make decisions about every single style choice (e.g., whether to put
"&&" at the beginning or end of the line, when expressions span multiple lines).
This is absolutely not what we want to do.
https://github.com/open-mpi/ompi/wiki/CodingStyle is intentionally very "light
touch": it only specifies a bare minimum of style rules -- the small number of
things that we could all agree on. Everything outside of those rules is not regulated.
Clang-format simply doesn't work that way: you have to make a decision for
every single style choice.
So we'll close https://github.com/open-mpi/ompi/pull/8816 and
https://github.com/open-mpi/ompi/pull/8923 without merging them.
If someone would like to find a better tool that can:
a) re-format the ompi/ and oshmem/ trees according to our "light touch" rules
b) fail a CI test when a PR introduces a delta that results in code breaking the
"light touch" rules
Then great: let's have that conversation. But clang-format is not going to
work for us, unfortunately. :-(
