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

[Félix-Antoine Constantin via cfe-commits]

felix642 wrote:

> You can use the CCC_OVERRIDE_OPTIONS environment variable to remove options.

I wasn't aware this was an option. This could definitely be an option to solve the linked issue!

> I don't think this would work, because it would need to be added to the GCC compile flags, and then those flags would be unknown to GCC?

Wouldn't this be the same issue no matter what option we add? GCC will not recognize the flag and complain. Unless the user adds them conditionally based on the compiler they are using. 
This is why I'm wondering if it would be better to only expose this option though the internal API of Clang and add an option to clang-tidy to make use of that feature. This way, it wouldn't be visible in the command line and there's no risk of GCC complaining about some options that it doesn't recognize. This would also give the possibility to other clang-based tool to implement it if they need to.

 > The problem I see with simply removing flags is that the code may not be analysed correctly, which may lead to other errors, which people will then ask us to patch, and so on.
 
 We're not removing those flags, we are simply downgrading the error to a warning. So there's still some feedback from clang that those flags we're not used. 
If a user reports an issue where the code doesn't compile because he forgot to add some flags, I don't see why we would have to patch anything on our side. But I do see your point, reporting a hard error forces the user to either remove or replace the flag with an equivalent one, but a warning can be easily overlooked.

> 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.

What I mean by "gcc-specific arrguments" is arguments that are recognized by GCC, but not clang for various reasons. The linked issue mentioned flags related to modules, but this PR is not related to modules specifically. There's a handful of flags that are not compatible with clang. @carlosgalvezp gave another example with some `-m` flags but there are others options like `-Wvla-larger-than`, `-fno-enforce-eh-specs`, `fextern-tls-init`, etc. 

> 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 agree with that. But the aforementioned flags would not prevent clang from compiling the code if they were ignored, they are simply used as optimization in the final binary. So the fact that clang-tidy refuses to analyze this code is more of a burden on the user knowing that this won't impact the final analysis. As previously mentioned, I do understand why this is a hard error. Clang doesn't know if it needs those flags or not so it's better to let the user fix it than to simply ignore them.

>  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.

I'm sorry if I misunderstand this part. I don't think I've mentioned adding some internal filtering logic to clang. If we decide to go forward and add an option to ignore some flags this has to be explicitly enabled by the user since this could cause some other issues if this was implicitly enabled. 

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