Use -fno-show-error-context from GHC 9.8

[dsaenztagarro]

Resolves #4281

Before the change, with GHC 9.8.1, this is how error messages look in Visual Studio Code:

After the change, this is how it looks now:

Notes

• b67871ecfb72220246c32825edd879d4e97a5cdd fixes following specs in this build

  See fixed specs

  

[michaelpj]

Looks great!

[michaelpj]

So it did work without changing the diagnostic printing options?

[michaelpj]

The failures look weird, I've restarted them just to see.

[dsaenztagarro]

So it did work without changing the diagnostic printing options?

@michaelpj exactly!, no need for changing diagnostic printing options.

It was completely my fault because I was using #if !MIN_VERSION_ghc(9,8,0) instead of #if MIN_VERSION_ghc(9,8,0), and so the changes were not applying, and the HLS code was not really recompiled.

[michaelpj]

Okay, so we have several problems.

Some of the tests are failing and they actually rely on matching against the error context! Argh! See https://github.com/haskell/haskell-language-server/blob/master/plugins/hls-refactor-plugin/src/Development/IDE/Plugin/CodeAction.hs#L810

I think that actually doesn't need to match on the error context and can be rewritten to just ignore the extra bits.

I'm not sure what's going on with the hole message, we should investigate what if anything is different about the message that GHC gives us and see if we can adapt the regexes to avoid the problem: https://github.com/haskell/haskell-language-server/blob/master/plugins/hls-refactor-plugin/src/Development/IDE/Plugin/Plugins/FillHole.hs#L14

[dsaenztagarro]

@michaelpj I debugged specifically the following failing spec regarding filling infix type hole:

cabal test hls-refactor-plugin-tests --test-option="-p /filling infix type hole uses prefix notation/"

And when looking to the relevant lines you suggested:

https://github.com/haskell/haskell-language-server/blob/7b8e2e504596f12a65167397d93e53ff1a7af0a0/plugins/hls-refactor-plugin/src/Development/IDE/Plugin/Plugins/FillHole.hs#L18-L20

I have found, while debugging, that comparing _message GHC payload before/after the changes, after the changes, the following part, that is used specifically in the regex comparison, it is lost:

8226 In the expression: a1 `_` a2
  In an equation for 8216test8217: test a1 a2 = a1 `_` a2

Looking at the rest of the payload, I can't see how we can still evaluate whether it is an infix hole. See below the full _message payload before/after the changes.

Before the change

``` 8226 Found hole: _ :: A -> A -> A 8226 In the expression: a1 `_` a2 In an equation for 8216test8217: test a1 a2 = a1 `_` a2 8226 Relevant bindings include a2 :: A (bound at /private/var/folders/ln/tvkm8dnn5pd8gz7hcpv9y_7m0000gn/T/extra-dir-28739387754/Test.hs:6:9) a1 :: A (bound at /private/var/folders/ln/tvkm8dnn5pd8gz7hcpv9y_7m0000gn/T/extra-dir-28739387754/Test.hs:6:6) test :: A -> A -> A (bound at /private/var/folders/ln/tvkm8dnn5pd8gz7hcpv9y_7m0000gn/T/extra-dir-28739387754/Test.hs:6:1) Valid hole fits include test foo asTypeOf const pure return seq Valid refinement hole fits include curry _ ($) _ ($!) _ const _ flip _ pure _ return _ id _ head _ last _ (Some refinement holefits suppressed; use -fmax-refinement-hole-fits=N or -fno-max-refinement-hole-fits) ```

After the change

``` 8226 Found hole: _ :: A -> A -> A 8226 Relevant bindings include a2 :: A (bound at /private/var/folders/ln/tvkm8dnn5pd8gz7hcpv9y_7m0000gn/T/extra-dir-17030982144/Test.hs:6:9) a1 :: A (bound at /private/var/folders/ln/tvkm8dnn5pd8gz7hcpv9y_7m0000gn/T/extra-dir-17030982144/Test.hs:6:6) test :: A -> A -> A (bound at /private/var/folders/ln/tvkm8dnn5pd8gz7hcpv9y_7m0000gn/T/extra-dir-17030982144/Test.hs:6:1) Valid hole fits include test foo asTypeOf const pure return seq Valid refinement hole fits include curry _ ($) _ ($!) _ const _ flip _ pure _ return _ id _ head _ last _ (Some refinement hole fits suppressed; use -fmax-refinement-hole-fits=N or -fno-max-refinement-hole-fits) ```

[dsaenztagarro]

Quick-update^tm: first of all thank you very much for all the support during the ZuriHac 2024,.. It would have been much harder to start being involved in the project without that initial push. Now, just some picks regarding the current state and my plans for the following weeks:

• I wrongly initially created a Pull request instead of a Draft request, so from now on, to avoid unnecessary noise to the Codeowners and the rest of maintainers, I will try to push changes only when reasonable sure that the changes will make it for different GHC versions locally. Update: I converted the PR this morning to Draft, but Codeowner may keep receiving notifications.
• I assume that I luck right now of the knowledge that I need to complete the job, so for now, I'm trying to get a deeper knowledge of ghc-exactprint and other libraries used in the project, so I have the tools to at least approach fixing the current failing specs with a good understanding of what I'm doing.
• Unless I get stack, I won't raise my hand, but I will leave a comment periodically to set the current status (let's say, once a month, unless you have any objection).
• If you consider this is urgent or needs to be managed faster, don't hesitate to ping me and I'm open to discuss all options.

[michaelpj]

Don't worry about pushing more, that's not a problem. And if you can point out where you're still getting stuck then maybe we can help!