================ @@ -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 _______________________________________________ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
