[cfe-dev] Silencing "unused argument" for injected default arguments
James Y Knight via cfe-dev
cfe-dev at lists.llvm.org
Fri Sep 27 06:12:36 PDT 2019
On Fri, Sep 13, 2019, 7:02 AM Martin Storsjö via cfe-dev <
cfe-dev at lists.llvm.org> 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.)
>
Why not just have the wrapper script use a config file? E.g. have it call
`clang --config whatever.conf`?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190927/eb3d166f/attachment.html>
More information about the cfe-dev
mailing list