GitLab

Both gcc and clang tell which warning flag a reported warning can be controlled with, e.g.

$ clang-3.5 -Wall -c hello.c
hello.c:3:7: warning: unused variable 'x' [-Wunused-variable]
  int x;
      ^
1 warning generated.

$ gcc -Wall -c hello.c
hello.c: In function ‘main’:
hello.c:3:7: warning: unused variable ‘x’ [-Wunused-variable]
   int x;
       ^
hello.c:4:1: warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^

With GHC however, we need to lookup the documentation (or memorise all warning flags) to find out which -fno-warn-* flag we need to use to silence a specific warning.

I propose we augment GHC's warnings in a similar style to how gcc/clang report flags in compile warnings.

---

As an obvious extension, (which maybe should be controlled by some -f flag, e.g. -f(no-)show-warning-groups), GHC could then also show by which warning-group a given warning is implied, e.g.

WCompatWarningsOn.hs:16:1: warning: [-Wsemigroup (in -Wcompat)]
    Local definition of ‘<>’ clashes with a future Prelude name.
    This will become an error in a future release.

WCompatWarningsOn.hs:22:3: warning: [-Wnoncanonical-monoid-instances (in -Wcompat)]
    Noncanonical ‘(<>) = mappend’ definition detected
    in the instance declaration for ‘Semi.Semigroup S’.
    Move definition from ‘mappend’ to ‘(<>)’

For the warning-sets which form a superset chain (Weverything > Wextra > Wall > Wdefault) we'd only mention the smallest one (and omit the trivial -Weverything set altogether) to keep the output concise.