[clang-tools-extra] [clang-tidy] Check for `-ignore-insert-conflict` support before using it in `apply_fixes` in `run-clang-tidy.py` (PR #127066)

[via cfe-commits]

Vicente Mataix =?utf-8?q?Ferrándiz?= <vmataix at altair.com>,
Vicente Mataix =?utf-8?q?Ferrándiz?= <vmataix at altair.com>,
Vicente Mataix =?utf-8?q?Ferrándiz?= <vmataix at altair.com>,
Vicente Mataix =?utf-8?q?Ferrándiz?= <vmataix at altair.com>
Message-ID:
In-Reply-To: <llvm.org/llvm/llvm-project/pull/127066 at github.com>


whisperity wrote:

I am a bit confused here. If you're using the **system** Clang toolchain assembled by your company (outside of your control), that toolchain should have delivered a `run-clang-tidy.py` that is appropriate for that version.

If you are using `run-clang-tidy.py` from the Git working directory obtained from upstream sources (i.e., `run-clang-tidy.py` is newer and has this flag), then all the other tools (including `clang-tidy` and `clang-apply-replacements`) should be the appropriate newer version.

Otherwise you might be mixing versions, standard library implementations, intrinsic headers, etc., and there will be plenty of subtle bugs lurking behind every corner!

So in general, what was the original point you're trying to achieve? To me, the solution to the lack of `-ignore-insert-conflict` in `clang-apply-replacements` would be to **build a newer `clang-apply-replacements`** and have that in the _`PATH`_ earlier than the system version. So your local `clang-tidy` binary, the `clang-apply-replacements`, and the `run-clang-tidy.py` are all appropriately from the same version.

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