Consistent use of sigs vs signatures in warnings

If I have a polymorphic local binding without a type signature, -Weverything complains:

warning: [-Wmissing-local-sigs]
    Polymorphic local binding with no type signature: ...

However, when I add -Wno-missing-local-sigs, I immediately get a deprecation warning

-Wno-missing-local-sigs is deprecated: it is replaced by -Wmissing-local-signatures

First, the warning with -Weveryting should use the non-depricated signatures version. Second, the deprecation warning should probably respect my use of no: -Wno-missing-local-sigs is replaced by -Wno-missing-local-signatures, not -Wmissing-local-signatures.

Obviously, check for similar cases with the other "sigs" options mentioned in #11583 (closed).

Trac metadata

Trac field	Value
Version	8.0.1
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related	#11583 (closed)
Blocking
CC
Operating system
Architecture

changed weight to 5

added Tbug Trac import labels

Trac metadata

Trac field	Value
TypeOfFailure	OtherFailure → IncorrectWarning
Related	#11583 (closed) → #10752 (closed), #11583 (closed)

added newcomer label

Hi! I've found the error. It seems that when looking for warning messages in DynFlags.hs/wWarningFlagsDeps for 'Opt_WarnMissingLocalSignatures' it finds first the depecrated version message. Swapping those two lines, getting something like this:

wWarningFlagsDeps :: [(Deprecation, FlagSpec WarningFlag)]
.....
flagSpec "missing-local-signatures"    Opt_WarnMissingLocalSignatures,
depFlagSpec "missing-local-sigs"       Opt_WarnMissingLocalSignatures
    "it is replaced by -Wmissing-local-signatures",
.....

solves this problem, but it is not the best solution. It is clear that there is an implicit order when looking for warning massages, and we need to check that function to see why it selects just the first it finds.

I am new to GHC development so I am still fighting with the code, and it may be worth open a new ticket to modify such function, and solve possibly any other 'bad warning massage'.

Cheers.

The function which uses this ordering is flagSpecOf. An acceptable solution would be to sort wWarningFlagsDeps there so that non deprecated flags are preferred to the deprecated versions.

Fixing the second problem looks more tricky, we can talk about it more once you've sorted out the first problem.

The second problem it is more tricky because the warning message for the deprecated flags is give to the 'EwM monad' with (correct me if I am wrong) the 'deprecate' function. So we need to delay this action until we know if we are in a "-Wno" situation,.

We can add a new String argument to the wWarningFlagsDeps, and something like this:

wWarningFlagsDeps :: [ (String -> (Deprecation, FlagSpec WarningFlag)) ]
...
\s -> depFlagSpec "missing-local-sigs"       Opt_WarnMissingLocalSignatures
    "it is replaced by " ++ s ++ "missing-local-signatures",
...

And of course all the modifications implied.

mentioned in commit f3be304a

closed

changed milestone to %8.2.1

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedFixed

added Pnormal label