[flang-commits] [flang] [flang] Add options -W[no-]unused-dummy-argument and -W[no-]unused-variable (PR #127214)

[Andrzej Warzyński via flang-commits]

================
@@ -932,10 +932,24 @@ static bool parseDiagArgs(CompilerInvocation &res, llvm::opt::ArgList &args,
     for (const auto &wArg : wArgs) {
       if (wArg == "error") {
         res.setWarnAsErr(true);
+      } else if (wArg == "unused-dummy-argument") {
+        res.getFrontendOpts().features.Enable(
+            Fortran::common::LanguageFeature::UnusedDummyArgument);
+      } else if (wArg == "no-unused-dummy-argument") {
+        res.getFrontendOpts().features.Enable(
+            Fortran::common::LanguageFeature::UnusedDummyArgument, false);
+      } else if (wArg == "unused-variable") {
+        res.getFrontendOpts().features.Enable(
+            Fortran::common::LanguageFeature::UnusedVariable);
+      } else if (wArg == "no-unused-variable") {
+        res.getFrontendOpts().features.Enable(
+            Fortran::common::LanguageFeature::UnusedVariable, false);
       } else {
-        const unsigned diagID =
-            diags.getCustomDiagID(clang::DiagnosticsEngine::Error,
-                                  "Only `-Werror` is supported currently.");
+        const unsigned diagID = diags.getCustomDiagID(
+            clang::DiagnosticsEngine::Error,
+            "Only `-Werror`, `-W[no]unused-dummy-argument` "
+            "and `-W[no]unused-variable` are supported "
+            "currently.");
----------------
banach-space wrote:

When we implemented this part, Flang had no mechanism to control diagnostics or warnings, which is why this logic is so basic. I see that this is slowly changing.

> This doesn't look like it is scalable.

Agreed - this is not a sustainable long-term approach. One way forward could be to take inspiration from Clang, for example: [clang/include/clang/Basic/DiagnosticGroups.td#L863](https://github.com/llvm/llvm-project/blob/055872acc28afdd8d29acdbec24f4bd415481d33).

My perspective on changes like this is that we shouldn't block them unless we can propose a concrete alternative. In practice, that means someone needs to design and implement a better approach.

@JDPailleux, are we expecting more patches like this in the near future? It would be helpful to understand the urgency of updating this logic.

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