AaronBallman wrote: > This is another attempt at fixing #108455. Please see the initial discussion > in the following PR: #111453
Thanks for investigating fixes here! > This parameter is used to suppress the `Unknown argument '...'` error that > clang will emit whenever it encounters an unknown argument. Personally, I'm not a big fan of having a command line option to control diagnostics of command line options. I think command line options are generally processed in a left-to-right order where the last flag "wins", which is kind of awkward with this design. e.g., `--allow-unrecognized-arguments --invalid` silencing the diagnostic but `--invalid --allow-unrecognized-arguments` not silencing the diagnostic. Processing the full command line to find `--allow-unrecognized-arguments` and then continuing to process the command line arguments is possible, but it begs the question of why that's not done for all options related to diagnostic output. I think this probably should remain an error. Passing unknown inputs to the compiler and expecting to get a known output is a pretty big ask IMO. That said, maybe others have a different opinion. > This is probably an error to make sure the user fixes it's mistake by either > removing the argument or renaming it, but there are some cases where it's not > possible to fix the issue. For instance, CMake now injects gcc-specific > arguments in the clang-tidy command that breaks static-analysis > (https://gitlab.kitware.com/cmake/cmake/-/issues/26283) IMO, that's a CMake bug; adding an option we have to support forever to work around that behavior is not really ideal. https://github.com/llvm/llvm-project/pull/162201 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits