Add code actions for missing type signatures

[jacg]

Will need more thorough testing, and maybe more discussion of the different approaches considered in #77.

[jacg]

One problem that I am observing locally, is that if I apply one of these actions in Emacs in the context of a larger file, then the signatures are sometimes garbled. As I seem to have lost the ability to apply code actions in VSCode, I can't tell whether this is an Emacs problem, or a problem with the implementation.

[jacg]

the signatures ar sometimes garbled

For example, adding the line foo = True just after the imports in ghcide/src/Development/IDE/LSP/CodeAction.hs and running the suggested action, results in

foo :: Bool
foo = True

If the same line is placed at the end of the same file, then the code action results in

fooo::oBool
foo = True

Similar story with abcdefgh a b c = True which gives abcdefgh :: p1 -> p2 -> p3 -> Bool or abcdefgh ::ap1b->cp2d-> p3 -> Bool.

[jacg]

The LSP log for the last one shows

  "contentChanges": [
    {
      "range": {
        "start": {
          "line": 238,
          "character": 0
        },
        "end": {
          "line": 238,
          "character": 8
        }
      },
      "rangeLength": 8,
      "text": "abcdefgh ::bp1c->dp2e-> p3 -> Bool\nabcdefgh"
    }
  ]

Which suggests that it's the server which is sending this nonsense?

[jacg]

Managed to get code actions working in VS Code once more: it all looks good over there, so this seems to be a problem with Emacs rather than this implementation.

[cocreature]

Looks great, thank you!

[jacg]

The big question that remains is what to do about enabling -Wmissing-signatures, without which none of this works.

The tests force the issue with {-# OPTIONS_GHC -Wmissing-signatures #-}.

Over in #77, @ndmitchell suggested

Maybe ghcide should always turn on this warning, always suggest it as a code action, but then if the user didn't turn on this warning, suppress the resulting warning notification.

Should I try doing it this way, or are there alternative proposals?

[jacg]

... or should we just merge it as is, and think deal with enabling the warnings in a separate PR?

[ndmitchell]

I think this is a great first step for people who enable this warning.

My ideal end state for everyone who doesn't enable the warning would be to have these quick fixes available, but not see even an info level diagnostic for missing signatures. I'm not sure if you can attach a quick fix without a diagnostic. The other option would be that top-level signatures that are omitted show up as code lenses, so you see:

foo :: Int -> Int
foo 1 =1

But the foo :: Int -> Int line is a hyperlink that's useful documentation, but if you click it, inserts the file for real. I could definitely see myself using that.

[jacg]

I think this is a great first step for people who enable this warning.

In which case I propose that we merge this as is, and leave further considerations for another PR.

[jacg]

But as it stands, it doesn't fully address #77, so I've removed the automatic closing.

[ndmitchell]

See #88 for how we should be doing inferred signatures if the warning is off, using the proper things in VS Code.

[maralorn]

Fwiw, I think. I would appreciate merging this and caring about the case without the warning enabled later.
That fits together with neils suggestion.

[cocreature]

Thank you for the PR and sorry for the delay!