[clang] [Clang][Driver] New parameter allow-unrecognized-arguments (PR #162201)

[Danny McClanahan via cfe-commits]

cosmicexplorer wrote:

Referring to command-line flags which clearly specify the standards documents they're referring to in the flag itself as "gcc-specific arguments" seems disingenuous and unprofessional. The reference to [Kitware's proposal](https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2022/p1689r5.html) is the first result from google. The [kitware issue](https://gitlab.kitware.com/cmake/cmake/-/issues/26283) clearly describes how to turn these off in the cmake file:

> `set(CMAKE_CXX_SCAN_FOR_MODULES OFF)`

> If we give the user the ability to run clang-based tools without any changes on they're project would, in my opinion, greatly simplify the integration of those tools in existing projects.

As I understand it, modules are a pretty fundamental change to the way C++ dependencies work. The [`clang-tidy` docs](https://clang.llvm.org/extra/clang-tidy/) state that:

> Clang compiler errors (such as syntax errors, semantic errors, or other failures that prevent Clang from compiling the code) are reported with the check name clang-diagnostic-error. These represent fundamental compilation failures that must be fixed before clang-tidy can perform its analysis. Unlike other diagnostics, clang-diagnostic-error cannot be disabled, as clang-tidy requires valid code to function.

I also see that `clang-tidy` has its own preferred flags for module support which do not implement any proposed standard:

```
  --enable-module-headers-parsing  - Enables preprocessor-level module header parsing
                                     for C++20 and above, empowering specific checks
                                     to detect macro definitions within modules. This
                                     feature may cause performance and parsing issues
                                     and is therefore considered experimental.
```

I also see that my locally installed copy of `clang` (version 20.1.8) already supports the exact same functionality, with very slightly misspelled names:

```
  -fmodule-map-file=<file>
                          Load this module map file
  -fmodules               Enable the 'modules' language feature
```

The linked issue regarding cmake describes these three arguments as problematic:
```
error: unknown argument: '-fdeps-format=p1689r5' [clang-diagnostic-error]
error: unknown argument: '-fmodule-mapper=my_exe/test/CMakeFiles/my_exe_lib_tests.dir/Debug/tests.cpp.o.modmap' [clang-diagnostic-error]
error: unknown argument: '-fmodules-ts' [clang-diagnostic-error]
```

The proposed methodology to directly ignore these inputs seems tantamount to a rejection of the proposals for interoperable module support across build systems.

> The main use case I see for this option would be to give the user the ability to run clang-tidy, clangd (or any clang-based tool as a matter of fact) on a gcc project and to get some decents results without having to maintain two separate build commands or to write some convoluted script to transform the gcc-based command line into something that clang will not complain about.

Given that modules are a standard API, and that clang already supports precisely the functionality needed, it's unclear why this is being described as "gcc-based". Is there context that's not being stated here?

> the "Unrecognized argument" is probably one of the only thing keeping them from doing that.

Given that my laptop's clang++ version supports very similar command-line arguments already, I'm curious why clang-tidy wouldn't be able to make use of that support from clang. Is there some deeper issue that stops clang-tidy from being able to support C++20 modules, or from using the code in clang that processes module dependencies?

Much like the make jobserver protocol that ninja and cargo now implement, gcc describes a very explicit effort of at least 5 years to get external buy-in for the exact functionality that is being described as "gcc-based" here (https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Module-Mapper.html):

> The mapper protocol was published as “A Module Mapper” https://wg21.link/p1184. The implementation is provided by libcody, https://github.com/urnathan/libcody, which specifies the canonical protocol definition. A proof of concept server implementation embedded in make was described in ”Make Me A Module”, https://wg21.link/p1602.

Removing arguments which define dependency relationships from the command line, based upon internal filtering logic that's defined in the specific version of clang-tidy's compiled C++ code and not in the build system, strikes me as a decision which could incur later user requests for an additional flag to cancel out the first flag filtering functionality, if the user ever figures out their dependency issue was because of this filtering logic in the first place.

In particular, many build systems such as bazel will cache process executions based upon the command-line arguments, especially if those arguments specify input files for the compiler to read. It would seem more appropriate to make such incompatibilities *visible* to the build system by writing diagnostics about unsupported flags to a separate output file, instead of subtly changing the semantics of command-line parsing in a data-dependent manner.

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