[clang-format] limiting search scope for .clang-format-ignore

[fancl20]

Currently .clang-format-ignore is searched in all parent directories, which creates a sometime unintuitive behavior: clang-format may be affected by a .clang-format-ignore config outside the project.

Should the search scope be limited by clang-format config or .git directory? It's difficult to notice what happened in these cases since .clang-format-ignore can be in any parent directory e.g. under home dir and the formatter get silently ignored.

[llvmbot]

@llvm/issue-subscribers-clang-format

Author: fancl20 (fancl20)

Currently `.clang-format-ignore` is searched in all parent directories, which creates a sometime unintuitive behavior: clang-format may be affected by a `.clang-format-ignore` config outside the project.

Should the search scope be limited by clang-format config or .git directory? It's difficult to notice what happened in these cases since .clang-format-ignore can be in any parent directory e.g. under home dir and the formatter get silently ignored.

[kainino0x]

I raised this issue initially over in Chromium. Here are the relevant parts of my investigation that led to this issue. Background: Chromium added chromium/src/third_party/.clang-format-ignore in order to avoid autoformatting code in chromium/src/third_party/*/ that is vendored into the repository. However, this unexpectedly also affected submodule dependencies living in chromium/src/third_party/*/ when doing local development on those dependencies in-place inside Chromium.

For third_party dependencies added via DEPS, this requires us to add .clang-format-ignore files upstream, for example, chromium/src/third_party/dawn. Dawn is a separate repo, that is used both standalone and in Chromium. When clang-format runs, I believe that for each file it formats, it scans upward from that file to find the closest .clang-format file, and separately scans to find the closest .clang-format-ignore file. So, when Dawn is checked out under Chromium, and we are calling git cl format from chromium/src/third_party/dawn, clang-format discovers chromium/src/third_party/.clang-format-ignore. This is surprising because Dawn has its own dawn/.clang-format which is the top-level of the project.

However, I understand why clang-format works this way - it wouldn't really make sense to stop scanning for .clang-format-ignore just because a .clang-format is found. That would prevent using .clang-format in subdirectories of a project without also putting an extra copy of .clang-format-ignore there.

It seems clang-format can't know where the root of the project is, because they don't have a config file that indicates the project root.

That said, those are not the only way to guess the project root. I've seen a number of code analysis/formatting tools that will stop traversing at git roots (directories that have a .git directory or file in them), at least by default. Some tools do this in the downward direction too (especially those which allow config to contain arbitrary scripts).

In git cl format (Chromium's wrapper script around clang-format) specifically, there is a clear project root - because it's a git command. If we could tell clang-format about the project root directory, then we should, so it doesn't pick up random config files from outside the project. Unfortunately, I don't see any such capability in clang-format --help.

[owenca]

Most of the feature requests here have been addressed by the new OneLineFormatOffRegex option.

[fancl20]

Maybe I missed something but from my reading OneLineFormatOffRegex only turns of the formatting when the line matches the pattern.

What we want is that for vendored code, turn off formatter altogether at directory/project level. The problem is, .clang-format-ignore has a scope neither match .git or .clang-format which can be confusing (e.g. affect submodule in the example above).

[owenca]

My apology. The comment was meant for #98165.