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 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
