Repository navigation
!!MISSING: command!! is intermittently displayed instead of type class function signatures #3827
Description
Your environment
Which OS do you use?
Macbook Air M2 15" (Ventura 13.6)
Intel x86_64 (Ubuntu 20.04.6 LTS)
Same issue on both systems.
Which version of GHC do you use and how did you install it?
Installed with ghcup:
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 9.6.3
$ cabal --version
cabal-install version 3.10.1.0
compiled using version 3.10.1.0 of the Cabal library
How is your project built (alternative: link to the project)?
https://github.com/konnik/haskell-json-parser
Which LSP client (editor/plugin) do you use?
VSCode + haskell.haskell
Which version of HLS do you use and how did you install it?
$ haskell-language-server-wrapper --version
haskell-language-server version: 2.3.0.0 (GHC: 9.2.8) (PATH: /Users/niklas/.ghcup/hls/2.3.0.0/lib/haskell-language-server-2.3.0.0/bin/haskell-language-server-wrapper)
Installed by ghcup
Have you configured HLS in any way (especially: a hie.yaml file)?
no
Steps to reproduce
Really don't know how to reproduce it. It's very intermittent and resolves itself.
Expected behaviour
The code lens (don't know if this is the correct termiology) in vscode should show the type class signatures on my instance:
instance Monad Parser where
return :: a -> Parser a // this is shown by vscode, not part of the source
return = pure
(>>=) :: Parser a -> (a -> Parser b) -> Parser b // this is shown by vscode, not part of the source
pa >>= fab = Parser $ \input -> do
(input', a) <- runParser pa input
runParser (fab a) input'Actual behaviour
instance Monad Parser where
!!MISSING: command!! // this is shown by vscode, not part of the source
return = pure
!!MISSING: command!! // this is shown by vscode, not part of the source
pa >>= fab = Parser $ \input -> do
(input', a) <- runParser pa input
runParser (fab a) input'If i click on the text "!!MISSING: command!!" the error message "command 'missing' not found" is shown in bottom right of vscode
Debug information
Some things from the logs. Don't know if its relevant:
2023-10-03T17:41:54.161080Z | Info | Typechecking reverse dependencies for NormalizedFilePath "/Users/niklas/devel/haskell-json-parser/src/Json.hs": [ NormalizedFilePath "/Users/niklas/devel/haskell-json-parser/test/Test.hs" ]
2023-10-03T17:42:08.500584Z | Warning | Typechecked a file which is not currently open in the editor: /Users/niklas/devel/haskell-json-parser/src/Json.hs
This can indicate a bug which results in excessive memory usage.
This may be a spurious warning if you have recently closed the file.
If you haven't opened this file recently, please file a report on the issue tracker mentioning the HLS version being used, the plugins enabled, and if
Activity
konnik commentedon Oct 3, 2023
Ok, have made some more investigations and found this in the server logs (verbose):
I'm not able to reproduce it consistently yet but the issue seems to occur more often when I constantly scroll the source from top to bottom and back.
konnik commentedon Oct 3, 2023
Here is a longer part of the log. I'm not sure but it seems that the issue occurs in combination of:
michaelpj commentedon Oct 4, 2023
cc @joyfulmantis , this seems like a resolve issue?
joyfulmantis commentedon Oct 4, 2023
I believe this is a vscode issue. We can't respond to stale resolve requests, and in those cases we respond with the correct error code. Instead of displaying no command vscode shouldn't display the lens at all.
konnik commentedon Oct 4, 2023
I've been able to reproduce it on Intel x86_64 / Ubuntu also.
I can open an issue on vscode-haskell if you think it's a problem on the client side.
joyfulmantis commentedon Oct 5, 2023
I believe the place where you want to open an issue is either vscode's official language server client package or the vscode repository .
fendor commentedon Oct 18, 2023
Closing as we believe this is not our fault and needs to be raised in vscode.
michaelpj commentedon Nov 7, 2023
I'm unsure about this. Maybe we should instead return the original item without new fields filled in in this case? It's unclear.
joyfulmantis commentedon Nov 7, 2023
I doubt doing that would fix it in that case, as it still would be a lens without a command
michaelpj commentedon Nov 7, 2023
I guess you're right. The only thing we could do would be to back out the resolve support, or somehow make it possible for stale resolve requests to be more likely to work.
michaelpj commentedon Nov 7, 2023
I found the corresponding code in
vscodeand opened an issue: microsoft/vscode#197643joyfulmantis commentedon Dec 4, 2023
@michaelpj Do we need to remove resolve here or rework it to be more successful because of vscodes's position vis a vis resolve failure? microsoft/vscode#197643 (comment)
michaelpj commentedon Dec 4, 2023
I don't know what to do tbh. It seems like their position is "resolve should be very reliable", and I'm not sure that that's something we can promise...
FWIW, I haven't observed this happening to me much (but then I use emacs not vscode, and I'm not sure how emacs deals with it). Perhaps we can leave this open and see if we get more people complaining.
One thing we might want to do is offer some configuration options about whether to use resolve. That's somewhat consistent with what we do for other features, you can generally e.g. turn off code lenses for a plugin, maybe you should also be able to turn off code-lens-resolve 🤔 That way at least if it's really misbehaving for people they can turn it off...
michaelpj commentedon Dec 13, 2023
Another thought: could we use a more robust key for some of the resolve functions? e.g. for type lenses we could probably use something like the combination of line-in-file and binding-name to identify a lens target. Then when we resolve we can get the fresh information about the file, see if there is still a binding with that name on that line, and if so continue resolving it.
WDYT @joyfulmantis ?
han-tyumi commentedon Dec 26, 2023
I'm quite new to the Haskell community.
I've been running into this and have been reloading the window as I thought something had broke.
But it sounds like it's actually "reloading" these lenses.
And indeed, just waiting a bit longer, it eventually comes back with the expected code lens.
At least I now know what is actually happening when I see
!!MISSING: command!!.If a solution may take a while, maybe a note somewhere about this would be nice?
joyfulmantis commentedon Dec 28, 2023
I think that is an idea we can explore. I think the reason why I originally chose to have these transient keys that we currently have, was to avoid having to process information multiple times. However, we could keep the current keys, and then add more information that allows us to compute the new lens if the key is stale.
michaelpj commentedon Dec 28, 2023
I guess I was hoping that we still wouldn't have to redo work? We can still use basically the same structure, I'm really just proposing a different key type. i.e. what if we actually just used
(LineNumber, OccName)as the key for code lens resolve?Generally we don't have a good way of doing this in a way that's actually visible to users. For now, I think having something visible on the issue tracker is the best thing we can do...