How to control the display of type signature lenses

[jneira]

• With this flag the user signals he wants ghc warns about type signatures of exported definitions and not for all top level definitions
• It would be nice follow that signal and only show type signature for those exported symbols and no all of them

(Suggested in fp discord channel by @edmundnoble)

[jneira]

It seems that it already should work 😉
//cc @berberman

[berberman]

Great!

Here is another approach: we could produce hidden diagnostics for suggesting top-level type signatures by ourselves, rather than setting Opt_WarnMissingSignatures and Opt_WarnMissingPatternSynonymSignatures in typecheck. Reasons:

• if we accept Retrieve Type from typecheck result for type lenses #1471, we will no loger rely on diagnostic messages from GHC. Instead, we traverse renamed ASTs to find out the name of identifer (by location we get from the diagnostic). Once we get the name, for global bindings, we look up the type environment; and for local bindings, we use HieAst to get type information of the identifer. Producing missing top-level signatures warnings is done in the renaming pass by GHC, and we could recover required information from TcGblEnv. So we could do this, and we don't have to traverse renamed ASTs to find the identifer if we do so.
• This mechanism will not be interfered by ghc options set by users.
• We could provide a user friendly interface to configure the display of type lenses (for example, fully disabled, only for exported bindings, fully enabled, etc.), otherwise users have to figure out obscure combinations of ghc options which can control this behaviour.

As for local bindings, iirc GHC producing missing signatures warnings in typecheck pass, which uses some intermediate values we can't access to, so we still have to use diagnostics from GHC. Anyway, we havn't set Opt_WarnMissingLocalSignatures in typechecking, right? This is left to users, and we just need keep the original behavior.

cc @pepeiborra

[jneira]

Great!

To be clear, i've not tested it, only saw your comment in discord

[berberman]

Great!

To be clear, i've not tested it, only saw your comment in discord

OK... at least it works on my machine.

[pepeiborra]

This issue is confusing. If this is already working, perhaps either close the issue or change the title?

@berberman if we produce the sigs ourselves, why do we need hidden diagnostics at all?

@berberman I don't agree that GHC flags are obscure. I think it could be perhaps a little surprising that GHC flags change the behaviour of HLS.

In any case, I am ambivalent about using plugin config VS GHC flags. The former is more deliberate, the latter are more widely known and much better documented

[berberman]

perhaps either close the issue or change the title?

Yes, the title should be changed to something like "How to control the display of type signature lenses".

if we produce the sigs ourselves, why do we need hidden diagnostics at all?

Ignore me, we don't need diagnostics in this case at all.

I think it could be perhaps a little surprising that GHC flags change the behaviour of HLS.

Yeah, that's what I mean. For this issue, we could have a better documentation on the effect on type lenses by GHC flags.

[jneira]

In any case, I am ambivalent about using plugin config VS GHC flags. The former is more deliberate, the latter are more widely known and much better documented

Agree, we could use both adding a config option "Use ghc flags" (or whatever meaningful name)
(and then disscuss what should be the default :-P)

[berberman]

FYI after https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4741, setting -Wmissing-exported-signatures to override -Wmissing-signatures won't work.