[clang] [clang-format] extend clang-format directive with options to prevent formatting for one line (PR #118566)

[Oleksandr T. via cfe-commits]

a-tarasyuk wrote:

> If we were to add // clang-format off-next-line, would "next line" mean the next physical or logical/unwrapped line?

I would expect it to apply only to the physical line, similar to how other formatters work. However, the main concern doesn’t seem to be about its behavior but rather about extending clang-format directive with new options at all.

> To me the current // clang-format off/on is enough, for everything else log an issue, or better still submit a pull request.

In most cases where users find the formatting unacceptable, they tend to disable it, while only a narrow group take the initiative to address the root cause by submitting pull requests or suggesting new rules. For instance, a [search for `clang-format` usage](https://shorturl.at/SFNGZ) on GitHub, even just for C++, shows hundreds of uses across various scenarios. Analyzing all of them and covering them with new rules would take a significant amount of time,. anyway, we can assume that these options are not without value.

>From my perspective, these options are just additional ways to control formatting and give users more flexibility. These options aren’t intended to eliminate `clang-format` usage, and based on user feedback on the issue, it seems there are cases in which these options are useful. For [instance](https://github.com/athomps/lammps/blob/ceb9466172398e9a20cb510528b4b17f719c7cf2/src/set.h#L15-L17),

```cpp
// clang-format off
CommandStyle(set,Set);
// clang-format on
```

vs

```cpp
CommandStyle(set,Set); // clang-format off-line
```

We don't know the context of why it was disabled. However, I would use `// clang-format off-line` in a similar way to `// NOLINT`., it's up to personal preference.

If these options introduce significant complexity that could lead to regressions without improving the development experience, I believe the discussion should be wrapped up, and both the PR and issue should be closed. Otherwise, it would be helpful to continue the discussion in the issue to gather more insights into why users need these changes. Does that make sense?

















https://github.com/llvm/llvm-project/pull/118566