Unable to determine that the file contains an error unless force CocRestart

[C-alcium]

Your environment

haskell-language-server version: 0.7.0.0 (GHC: 8.10.1) (PATH: /home/calc/.ghcup/bin/haskell-language-server-wrapper-0.7.0) (GIT hash: 6a692de3308c06d8eb7bdf0f7b8a35b6e9a92610)
Tool versions found on the $PATH
cabal:		3.2.0.0
stack:		2.5.1
ghc:		8.8.4

Which lsp-client do you use:
coc.nvim for NeoVim

Contents of hie.yaml:

cradle:
  stack:
    - path: "./lib"
      component: "HinfoBot:lib"

    - path: "./src"
      component: "HinfoBot:exe:HinfoBot"

Steps to reproduce

0. Screenshot text

main' :: IO () 
main' = do 
  let res = Just "Hello"
  case res of 
    Nothing -> print "Nothing"
    (Just a) -> print a

1. Given the below screenshot
   

2. remove a
   

3. Notice there is no error prompt, remember that coc.nvim includes information in the FAQ about how some language servers will not work on buffered text, so save the file with :w
   

4. Still no error, attempt to perform a documentation lookup using shift + k (my personal binding, used to force an onHover call).

5. Observe that only now after manually calling to the server does it present an error:
   

Expected behaviour

When I write the file, I should be notified that I have a type error

Actual behaviour

No error is present until I force a documentation lookup, or call :CocRestart

Debug log output

Found "/home/calc/dev/HinfoBot/hie.yaml" for "/home/calc/dev/HinfoBot/a"
Module "/home/calc/dev/HinfoBot/a" is loaded by Cradle: Cradle {cradleRootDir = "/home/calc/dev/HinfoBot", cradleOptsProg = CradleAction: Stack}
Run entered for haskell-language-server-wrapper(haskell-language-server-wrapper) Version 0.7.0.0, Git revision 6a692de3308c06d8eb7bdf0f7b8a35b6e9a92610 (dirty) x86_64 ghc-8.10.1
Current directory: /home/calc/dev/HinfoBot
Operating system: linux
Arguments: ["--debug"]
Cradle directory: /home/calc/dev/HinfoBot
Cradle type: Stack

Tool versions found on the $PATH
cabal:		3.2.0.0
stack:		2.5.1
ghc:		8.8.4


Consulting the cradle to get project GHC version...
Project GHC version: 8.8.4
haskell-language-server exe candidates: ["haskell-language-server-8.8.4","haskell-language-server-8.8","haskell-language-server"]
Launching haskell-language-server exe at:/home/calc/.ghcup/bin/haskell-language-server-8.8.4
haskell-language-server version: 0.7.0.0 (GHC: 8.8.4) (PATH: /home/calc/.ghcup/bin/haskell-language-server-8.8.4~0.7.0) (GIT hash: 6a692de3308c06d8eb7bdf0f7b8a35b6e9a92610)
(haskell-language-server)Ghcide setup tester in /home/calc/dev/HinfoBot.
Report bugs at https://github.com/haskell/haskell-language-server/issues

Tool versions found on the $PATH
cabal:		3.2.0.0
stack:		2.5.1
ghc:		8.8.4


Step 1/4: Finding files to test in /home/calc/dev/HinfoBot
Found 3 files

Step 2/4: Looking for hie.yaml files that control setup
Found 1 cradle

Step 3/4: Initializing the IDE

Step 4/4: Type checking the files
[INFO] Consulting the cradle for "lib/NewsAPI.hs"
Output from setting up the cradle Cradle {cradleRootDir = "/home/calc/dev/HinfoBot", cradleOptsProg = CradleAction: Stack}
> The following GHC options are incompatible with GHCi and have not been passed to it: -threaded
> Configuring GHCi with the following packages: HinfoBot
> /home/calc/dev/HinfoBot/.stack-work/install/x86_64-linux-tinfo6/f64016d8294d61070b7e6453655c2ba01b8fe4f231a7d68a8057bbbd47142ef1/8.8.4/pkgdb:/home/calc/.stack/snapshots/x86_64-linux-tinfo6/f64016d8294d61070b7e6453655c2ba01b8fe4f231a7d68a8057bbbd47142ef1/8.8.4/pkgdb:/home/calc/.stack/programs/x86_64-linux/ghc-tinfo6-8.8.4/lib/ghc-8.8.4/package.conf.d
[INFO] Using interface files cache dir: ghcide
[INFO] Making new HscEnv[main]
[INFO] Consulting the cradle for "src/Main.hs"
Output from setting up the cradle Cradle {cradleRootDir = "/home/calc/dev/HinfoBot", cradleOptsProg = CradleAction: Stack}
> Using main module: 1. Package `HinfoBot' component HinfoBot:exe:HinfoBot with main-is file: /home/calc/dev/HinfoBot/src/Main.hs
> The following GHC options are incompatible with GHCi and have not been passed to it: -threaded
> Configuring GHCi with the following packages: HinfoBot
> /home/calc/dev/HinfoBot/.stack-work/install/x86_64-linux-tinfo6/f64016d8294d61070b7e6453655c2ba01b8fe4f231a7d68a8057bbbd47142ef1/8.8.4/pkgdb:/home/calc/.stack/snapshots/x86_64-linux-tinfo6/f64016d8294d61070b7e6453655c2ba01b8fe4f231a7d68a8057bbbd47142ef1/8.8.4/pkgdb:/home/calc/.stack/programs/x86_64-linux/ghc-tinfo6-8.8.4/lib/ghc-8.8.4/package.conf.d
[INFO] Using interface files cache dir: ghcide
[INFO] Using interface files cache dir: ghcide
[INFO] Making new HscEnv[main,main]
[INFO] Consulting the cradle for "Setup.hs"
Output from setting up the cradle Cradle {cradleRootDir = "/home/calc/dev/HinfoBot", cradleOptsProg = CradleAction: Stack}
File:     /home/calc/dev/HinfoBot/Setup.hs
Hidden:   no
Range:    1:1-2:1
Source:   cradle
Severity: DsError
Message: 
  Multi Cradle: No prefixes matched
  pwd: /home/calc/dev/HinfoBot
  filepath: /home/calc/dev/HinfoBot/Setup.hs
  prefixes:
  ("./lib",Stack {component = Just "HinfoBot:lib", stackYaml = Nothing})
  ("./src",Stack {component = Just "HinfoBot:exe:HinfoBot", stackYaml = Nothing})
Files that failed:
 * /home/calc/dev/HinfoBot/Setup.hs

Completed (2 files worked, 1 file failed)
haskell-language-server-wrapper: callProcess: /home/calc/.ghcup/bin/haskell-language-server-8.8.4 "--debug" (exit 1): failed

Notes

Perhaps this is a Coc.nvim issue? I am really not sure

[Ailrun]

Does your log contain both before and after you restart HLS, or it is only for after the restart? The log itself looks fine...

[C-alcium]

I performed the edits you seen and then ran the command to produce the log, so I'm not sure, but if there's a specific order I need to run things then let me know.

[C-alcium]

Just looking into this, perhaps there is a way to abuse autocmd to automatically call CocRestart or a doclookup or similar function to work around this in the interim?

[jneira]

@expipiplus1 iirc you were using neovim, are you experiencing this?

[expipiplus1]

I've not experienced anything like this, live errors have always worked well for me. Note that errors will not be updated until you leave insert mode. My coc config is here: https://github.com/expipiplus1/dotfiles/blob/master/config/nixpkgs/home/coc-nvim.nix#L169 I also have a program which tests this exact scenario: https://github.com/expipiplus1/dotfiles/blob/master/tests/vim-hls-error.nix#L7

…

On Sat, Dec 26, 2020, 3:06 AM Javier Neira ***@***.***> wrote: @expipiplus1 <https://github.com/expipiplus1> iirc you were using neovim, are you experiencing this? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#696 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGRJXFMMZB7MVJYXP56RZ3SWTPBHANCNFSM4VH2LS3A> .

[C-alcium]

I've not experienced anything like this, live errors have always worked well for me. Note that errors will not be updated until you leave insert mode. My coc config is here: https://github.com/expipiplus1/dotfiles/blob/master/config/nixpkgs/home/coc-nvim.nix#L169 I also have a program which tests this exact scenario: https://github.com/expipiplus1/dotfiles/blob/master/tests/vim-hls-error.nix#L7
…
On Sat, Dec 26, 2020, 3:06 AM Javier Neira @.***> wrote: @expipiplus1 https://github.com/expipiplus1 iirc you were using neovim, are you experiencing this? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#696 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGRJXFMMZB7MVJYXP56RZ3SWTPBHANCNFSM4VH2LS3A .

Hey there, nice of you to highlight this - I tried having a look at your configuration to see what delta there would be between it and my own config, and they're fairly different since you are using nix. Do you get the same issue using the default configuration with stack, or would this make a difference at all?

Just to point out some additional information, what you said about insert mode seems to be the opposite of true for my case. If you refer back to my example, if I use x in normal mode to delete the a, it works fine. If I enter insert mode, delete the a and then leave insert mode and write the file, it cannot detect it. I figured that the mode swapping issue here is definitely coc.nvim's responsibility, but imo it should definitely be able to see the errors after I have explicitly wrote the file, right?

[expipiplus1]

That configuration is rendered 1-1 into the JSON coc configuration, so aside from the syntax it should be easily comparable. I don't think there would be any difference using stack here.

…

On Sat, Dec 26, 2020, 11:23 AM C-alcium ***@***.***> wrote: I've not experienced anything like this, live errors have always worked well for me. Note that errors will not be updated until you leave insert mode. My coc config is here: https://github.com/expipiplus1/dotfiles/blob/master/config/nixpkgs/home/coc-nvim.nix#L169 I also have a program which tests this exact scenario: https://github.com/expipiplus1/dotfiles/blob/master/tests/vim-hls-error.nix#L7 … <#m_-6946108095412057132_> On Sat, Dec 26, 2020, 3:06 AM Javier Neira *@*.***> wrote: @expipiplus1 <https://github.com/expipiplus1> https://github.com/expipiplus1 iirc you were using neovim, are you experiencing this? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#696 (comment) <#696 (comment)>>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGRJXFMMZB7MVJYXP56RZ3SWTPBHANCNFSM4VH2LS3A . Hey there, nice of you to highlight this - I tried having a look at your configuration to see what delta there would be between it and my own config, and they're fairly different since you are using nix. Do you get the same issue using the default configuration with stack, or would this make a difference at all? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#696 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGRJXCV34AHZW2EAVYGWRLSWVJKXANCNFSM4VH2LS3A> .

[C-alcium]

That configuration is rendered 1-1 into the JSON coc configuration, so aside from the syntax it should be easily comparable. I don't think there would be any difference using stack here.

I see -- I'm really not sure where to go here then, perhaps it is an environmental difference?

Edit: Same-same after I went through each property on the config file.

[C-alcium]

@expipiplus1 thanks for the link to your config, after much messing I found that oddly enabling codelens fixes this behaviour for some reason ??? Is this something that should be enabled by default?

I will say, I only just noticed it working properly when I toggled on this feature -- Although it does not detect any issues when I exit normal mode, only when I save the file. I don't really mind that. Surely this is a bug though? From what I could see the code lenses were for import lists.

[expipiplus1]

Very strange. If you can reduce this to a minimal project, vimrc and coc config I can see if I can reproduce.

…

On Sat, Dec 26, 2020, 9:35 PM C-alcium ***@***.***> wrote: @expipiplus1 <https://github.com/expipiplus1> thanks for the link to your config, after much messing I found that oddly enabling codelens fixes this behaviour for some reason ??? Is this something that should be enabled by default? I will say, I only just noticed it working properly when I toggled on this feature -- Although it does not detect any issues when I exit normal mode, *only* when I save the file. I don't really mind that. Surely this is a bug though? From what I could see the code lenses were for import lists. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#696 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGRJXBMVFN7KIDZZWC6R2DSWXRBBANCNFSM4VH2LS3A> .

[Avi-D-coder]

I have experienced something like this issue.
I have not yet had time to debug, but the behavior so far is similar or identical.

[C-alcium]

Something I want to mention is that I did clear out my stack folders and rebuild everything, I was reading the commit tagged on this PR earlier and while I recognize that is from July, that was something extra that I did. I have not had time to setup a reproducible sample (largely because doing so requires so much time and it is the holiday season) but perhaps that had something to do with it?