[cfe-dev] Silencing "unused argument" for injected default arguments

[Martin Storsjö via cfe-dev]

Hi,

Is there anyone who might have any good ideas on how to handle this, as 
described below? (Posting it right before CppCon might not have been the 
best timing for getting responses - hopefully people have more time 
now...)

// Martin

On Fri, 13 Sep 2019, Martin Storsjö via cfe-dev wrote:

> Hi,
>
> In my setups with clang, I'm using a thin frontend wrapper which passes a 
> bunch of custom defaults (allowing using any stock clang executable, 
> without requiring it to be built with CLANG_DEFAULT_* set to my desired 
> state). The main set of flags I currently use is this:
>
> -target $TARGET -rtlib=compiler-rt -stdlib=libc++ -fuse-ld=lld 
> -fuse-cxa-atexit
>
>
> Many of them are silent (like -fuse-ld=lld despite only compiling, not 
> linking), but e.g. -stdlib=libc++ is considered unused if compiling C 
> code. (Just looking at the driver name, clang vs clang++, isn't enough for 
> deciding to omit it; it could also be "clang -x c++" etc, and I'd prefer 
> not to try to deduce that in the wrapper.)
>
> In some cases it also adds a few -D and -Wl,-l<lib>, where the -Wl,-l also 
> warns while compiling.
>
> To mitigate this, I'm also adding -Qunused-arguments, which works fine, 
> but is a bit too overreaching.
>
> Would it make sense to add some mechanism to flag these arguments as 
> default ones that clang shouldn't warn about being unused?
>
> That could be something like --start-no-unused-arguments <args> 
> --end-no-unused-arguments.
>
> I know about the clang config files, which also allows setting default 
> flags, which are exempt from unused warnings, and I've tried that, but for 
> various reasons I'm still more comfortable with setting them via a 
> wrapper. (E.g. on windows, the config file setup would require having N 
> copies of clang.exe, one for each triple combination, while I currently 
> can do with just copies of the wrapper and one single clang.exe.)
>
> // Martin
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>