[llvm-branch-commits] [clang] [Multilib] Custom flags processing for library selection (PR #110659)

[Simon Tatham via llvm-branch-commits]

================
@@ -14,6 +14,12 @@ def err_drv_no_such_file_with_suggestion : Error<
 def err_drv_unsupported_opt : Error<"unsupported option '%0'">;
 def err_drv_unsupported_opt_with_suggestion : Error<
   "unsupported option '%0'; did you mean '%1'?">;
+def warn_drv_unsupported_opt : Warning<
+  "unsupported option '%0'">,
+  InGroup<UnusedCommandLineArgument>;
+def warn_drv_unsupported_opt_with_suggestion : Warning<
+  "unsupported option '%0'; did you mean '%1'?">,
+  InGroup<UnusedCommandLineArgument>;
----------------
statham-arm wrote:

You mention in the commit message that an unrecognised custom flag is a warning rather than an error. But I'm curious about why. If a toolchain vendor ships a toolchain with a collection of flags that select particular libraries, and a user misspells a flag in their makefile, why _wouldn't_ they want a build error so that they notice and fix it? A warning can easily be scrolled off the screen in the enormous build log.

Warnings are for cases that _might_ be mistakes by the user, but might also be correct, so you can't afford to refuse to build. I don't see why an unrecognised flag falls into that category.

It would make sense if there was some kind of standard flag that _most_ multilib collections agreed on, and you wanted to be able to use that flag everywhere and have it quietly ignored when not supported. But is that your intention?

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