Silencing "unused argument" for injected default arguments

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

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

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),

-fuse-ld=lld when compiling does warn:
$ clang+±tot foo.cpp -fuse-ld=lld -c
clang-10: warning: argument unused during compilation: ‘-fuse-ld=lld’ [-Wunused-command-line-argument]

but e.g. -stdlib=libc++ is considered unused if compiling C
code.

Same “argument unused during compilation” here, as you say.

I don’t know that there’s much worthwhile to add to Clang to support this scenario, but I could be wrong/am but one voice here.

Usually the way to get different flags to different parts of the build is with the various build variables (like CFLAGS, CXXFLAGS, CC, CXX, LDFLAGS, etc).

      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),

-fuse-ld=lld when compiling does warn:
$ clang++-tot foo.cpp -fuse-ld=lld -c
clang-10: warning: argument unused during compilation: '-fuse-ld=lld'
[-Wunused-command-line-argument]

Oh, that's surprising. If you add "-target x86_64-w64-mingw32" the warning does go away, but not with e.g. "-target x86_64-linux-gnu" - so apparently the -fuse-ld flag is unconditionally consumed by the mingw target code.

      but e.g. -stdlib=libc++ is considered unused if compiling C
      code.

Same "argument unused during compilation" here, as you say.

I don't know that there's much worthwhile to add to Clang to support this
scenario, but I could be wrong/am but one voice here.

Usually the way to get different flags to different parts of the build is
with the various build variables (like CFLAGS, CXXFLAGS, CC, CXX, LDFLAGS,
etc).

Yeah, but those are more for the user/buildsystem to set than for the toolchain installation itself.

I guess I could try implementing --start-no-unused-arguments and --end-no-unused-arguments and see how palatable it ends up being. If it's not too bad it'd hopefully be tolerable even though it's a fringe usecase.

// Martin

Why not just have the wrapper script use a config file? E.g. have it call clang --config whatever.conf?

That could work, although it's a little bit less convenient than my current setup. It ends up as quite a few files, as there's currently 4 different archs, times two environment variants (plain desktop or the UWP environment), giving currently 8 different files to keep in sync (or automate generation of).

// Martin