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

Reply via email to