That sounds awesome; many thanks, Joseph.
On May 18, 2021, at 10:53 AM, Joseph Schuchart via devel <devel@lists.open-mpi.org<mailto:devel@lists.open-mpi.org>> wrote: 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. :-( -- Jeff Squyres jsquy...@cisco.com<mailto:jsquy...@cisco.com>
