It's one of the warning I disable most frequently (in application code only of course!).
I wonder if it's even worth not suggesting this in library code, or if the inconsistency would just be confusing.
Just an idea, I'm sure it's not to everyone's taste!
We definitely shouldn't suggest it unless the user has explicitly asked for it. Do you believe we do so?
I think more generally an action available on any warning should be to disable the warning. I don't think people should use it too often, but it's a nice time saver.
Do I believe we do what, sorry?
This certainly does generalize to any warning, but nearly all warnings I squash properly except for this one which I almost always ignore. Perhaps it would be better just to leave it in my ghc-opts.
Perhaps this warning ignoring suggestion could be general, but also parameterized by the user for which ones to trigger on
Ignore <warning name> for line and Ignore <warning name> for file is pretty common code actions for warnings in other servers. GHC can't ignore warning for specific line, IIRC, but generic Ignore <warning name> for module and Ignore <warning name> for project makes sense to me.
:+1:
That option also exists in java ides, you can disable warnings per project (so the ide calls the compiler with the appropiate flags) or it suggests you add the proper annotation to disable it for a concrete definition (class, method or variable).
@expipiplus1 - I believe that unless you have explicitly asked for it, we won't warn on orphans, so you must have turned it on in your project. Probably through -Wall.
Most helpful comment
Ignore <warning name> for lineandIgnore <warning name> for fileis pretty common code actions for warnings in other servers. GHC can't ignore warning for specific line, IIRC, but genericIgnore <warning name> for moduleandIgnore <warning name> for projectmakes sense to me.