# HLS 2.5.0.0 is now available

**URL:** <https://discourse.haskell.org/t/hls-2-5-0-0-is-now-available/8244>\
**Category:** Uncategorized\
**Created:** [December 1, 2023, 1:33pm UTC](https://discourse.haskell.org/t/hls-2-5-0-0-is-now-available/8244 "2023-12-01T13:33:04Z")\
**Posts on this page:** 18\
**Page:** 1

<div class="post-metadata">

**Author:** ![wz1000](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/wz1000/32/1245_2.png) [@wz1000](https://discourse.haskell.org/u/wz1000)\
**Post date:** [December 1, 2023, 1:33pm UTC](https://discourse.haskell.org/t/hls-2-5-0-0-is-now-available/8244/1 "2023-12-01T13:33:05Z")

</div>

Binaries for this release are available at  
[Index of /~hls/haskell-language-server-2.5.0.0/](https://downloads.haskell.org/~hls/haskell-language-server-2.5.0.0/).

These binaries can be installed using [GHCup](https://www.haskell.org/ghcup/), using the vanilla metadata channel.

```bash
ghcup --url-source=https://raw.githubusercontent.com/haskell/ghcup-metadata/master/ghcup-vanilla-0.0.8.yaml install hls 2.5.0.0

```

All of these tarballs have associated GPG signatures. The signature should be from `Zubin Duggal <zubin@well-typed.com>` (key ID [588764FBE22D19C4](https://keys.openpgp.org/search?q=588764FBE22D19C4)).

The prebuilt binaries in this release support the following GHC versions:

- 9.2.8
- 9.4.8
- 9.6.3
- 9.8.1

# Changelog

- Bindists for GHC 9.4.8
- Drop support for GHC 9.0
- Re-add stan plugin
- Load default operator fixities in Fourmolu plugin

---

<div class="post-metadata">

**Author:** ![ocharles](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/ocharles/32/102_2.png) [@ocharles](https://discourse.haskell.org/u/ocharles)\
**Post date:** [December 1, 2023, 1:45pm UTC](https://discourse.haskell.org/t/hls-2-5-0-0-is-now-available/8244/2 "2023-12-01T13:45:38Z")

</div>

Does this also include improved support for multiple home units, or is that for the next release? I saw the pr recently merged

---

<div class="post-metadata">

**Author:** ![wz1000](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/wz1000/32/1245_2.png) [@wz1000](https://discourse.haskell.org/u/wz1000)\
**Post date:** [December 1, 2023, 1:51pm UTC](https://discourse.haskell.org/t/hls-2-5-0-0-is-now-available/8244/3 "2023-12-01T13:51:29Z")

</div>

No, that will be part of the next release, and will require a new cabal-install release (3.12 likely) to properly make use of, unless you use a custom bios.

---

<div class="post-metadata">

**Author:** ![janus](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/janus/32/1060_2.png) [@janus](https://discourse.haskell.org/u/janus)\
**Post date:** [December 10, 2023, 3:06pm UTC](https://discourse.haskell.org/t/hls-2-5-0-0-is-now-available/8244/4 "2023-12-10T15:06:59Z")

</div>

> [@wz1000](#):
>
> 9.4.8

@hasufell Does this mean 9.4.8 can now be ‘recommended’ in ghcup? I think I read somewhere that 9.4.7 was recommended because there was no HLS for 9.4.8.

---

<div class="post-metadata">

**Author:** ![hasufell](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/hasufell/32/1250_2.png) [@hasufell](https://discourse.haskell.org/u/hasufell)\
**Post date:** [December 11, 2023, 4:27am UTC](https://discourse.haskell.org/t/hls-2-5-0-0-is-now-available/8244/5 "2023-12-11T04:27:14Z")

</div>

Have you used HLS 2.5.0.0 yet? It’s not merely a bindist release, which I attempted to do first, until I hit severe issues, because HLS CI was relying on head.hackage, which was broken at the time. It includes code changes.

So we don’t bump a HLS to ‘recommended’ just because it’s newer. We want some time to pass to catch regressions.

Why are you interested in the ‘recommended’ tag? You can always just install latest if you’re keen. ‘recommended’ is for people who have low appetite to be beta testers for Haskell.

---

<div class="post-metadata">

**Author:** ![miguel-negrao](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/miguel-negrao/32/1948_2.png) [@miguel-negrao](https://discourse.haskell.org/u/miguel-negrao)\
**Post date:** [December 12, 2023, 2:45pm UTC](https://discourse.haskell.org/t/hls-2-5-0-0-is-now-available/8244/6 "2023-12-12T14:45:43Z")

</div>

What is the status of wingman ? thanks

---

<div class="post-metadata">

**Author:** ![Lsmor](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/lsmor/32/3302_2.png) [@Lsmor](https://discourse.haskell.org/u/Lsmor)\
**Post date:** [December 12, 2023, 3:49pm UTC](https://discourse.haskell.org/t/hls-2-5-0-0-is-now-available/8244/7 "2023-12-12T15:49:20Z")

</div>

> [@miguel-negrao](#):
>
> What is the status of wingman

I think it was abandoned: [Issue here](https://github.com/haskell/haskell-language-server/issues/2971#issuecomment-1503805278)

---

<div class="post-metadata">

**Author:** ![miguel-negrao](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/miguel-negrao/32/1948_2.png) [@miguel-negrao](https://discourse.haskell.org/u/miguel-negrao)\
**Post date:** [December 12, 2023, 5:49pm UTC](https://discourse.haskell.org/t/hls-2-5-0-0-is-now-available/8244/8 "2023-12-12T17:49:01Z")

</div>

Oh, I see… that’s depressing. I had hopes it might be coming back to life one day.

---

<div class="post-metadata">

**Author:** ![tomjaguarpaw](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/tomjaguarpaw/32/1230_2.png) [@tomjaguarpaw](https://discourse.haskell.org/u/tomjaguarpaw)\
**Post date:** [December 12, 2023, 8:31pm UTC](https://discourse.haskell.org/t/hls-2-5-0-0-is-now-available/8244/9 "2023-12-12T20:31:28Z")

</div>

> Just to reiterate; the hard part here is _updating the text buffer_ with the results of having synthesized new code

([Simpler Tier 1 tactics for case splits · Issue #3525 · haskell/haskell-language-server · GitHub](https://github.com/haskell/haskell-language-server/issues/3525#issuecomment-1469322994))

It’s surprising to me that that should be a blocker. It shouldn’t be for people who are willing to use an autoformatter, at least. Those people don’t much care about what the synthesised new code looks like! Exactprint seems irrelevant in such cases. Maybe I’m misunderstanding what exactly is involved here.

---

<div class="post-metadata">

**Author:** ![juhp](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/juhp/32/323_2.png) [@juhp](https://discourse.haskell.org/u/juhp)\
**Post date:** [December 14, 2023, 6:12pm UTC](https://discourse.haskell.org/t/hls-2-5-0-0-is-now-available/8244/10 "2023-12-14T18:12:17Z")

</div>

I have updated my [Fedora Copr repo](https://copr.fedorainfracloud.org/coprs/petersen/haskell-language-server/) to HLS 2.5 for ghc9.2, ghc9.4 and ghc9.6, for both Fedora Linux and EPEL 9.

You can see also the various builds on the [monitor page](https://copr.fedorainfracloud.org/coprs/petersen/haskell-language-server/monitor/detailed)

(The aarch64 failures on ghc9.4 and ghc9.6 are due to a static linking [issue](https://gitlab.haskell.org/ghc/ghc/-/issues/23842))

---

<div class="post-metadata">

**Author:** ![janus](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/janus/32/1060_2.png) [@janus](https://discourse.haskell.org/u/janus)\
**Post date:** [December 17, 2023, 8:57pm UTC](https://discourse.haskell.org/t/hls-2-5-0-0-is-now-available/8244/11 "2023-12-17T20:57:52Z")

</div>

> [@hasufell](#):
>
> Have you used HLS 2.5.0.0 yet?

I don’t use HLS, as I’ve had it trigger the OOM killer a couple of times. I’ve been working on large proprietary codebases though, so they are not representative.

> Why are you interested in the ‘recommended’ tag?

I do appreciate that you test things out and make sure things are only recommended once verified. But on the other hand, I do think it is odd how, as it currently stands, even minor compiler releases like 9.4.8 can’t be ‘recommended’ because related tooling isn’t synchronized yet. Maybe I am old-fashioned in not using HLS. I recognize that I am probably too focused on the GHC bug fixes and one has to compare the bugs getting fixed with the usability issues of somebody losing HLS support. I just hadn’t thought too much about this policy. It does make sense now, thank you.

---

<div class="post-metadata">

**Author:** ![hasufell](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/hasufell/32/1250_2.png) [@hasufell](https://discourse.haskell.org/u/hasufell)\
**Post date:** [December 17, 2023, 10:43pm UTC](https://discourse.haskell.org/t/hls-2-5-0-0-is-now-available/8244/12 "2023-12-17T22:43:36Z")

</div>

> [@janus](#):
>
> I’ve been working on large proprietary codebases though, so they are not representative.

There are some common HLS plugins that are memory hogs. You can disable all of them via lsp client config. GHC devs do that too afair, maybe @mpickering knows more.

> [@janus](#):
>
> But on the other hand, I do think it is odd how, as it currently stands, even minor compiler releases like 9.4.8 can’t be ‘recommended’ because related tooling isn’t synchronized yet.

I’m not the release manager for tooling. I’ve outlined many times what needs to happen for releases to go more smoothly.

Even minor GHC releases may require code changes in HLS afaiu, so ghcup can’t just build bindists ad-hoc. The GHC API doesn’t follow PVP afaiu.

Another proposed solution was to integrate HLS (the codebase) into GHC and force tighter coupling, but also synchronous releases. I’m not a fan.

The other approach is to, well, make an actually stable GHC API. I believe @lexi.lambda is working on that project.

---

<div class="post-metadata">

**Author:** ![Swordlash](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/swordlash/32/4604_2.png) [@Swordlash](https://discourse.haskell.org/u/Swordlash)\
**Post date:** [December 18, 2023, 12:04am UTC](https://discourse.haskell.org/t/hls-2-5-0-0-is-now-available/8244/13 "2023-12-18T00:04:34Z")

</div>

Is it possible to at least bring back the case autocompletion (meaning to fill out all missing cases of pattern match with placeholder code)? This was a very useful thing.

---

<div class="post-metadata">

**Author:** ![Bodigrim](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/bodigrim/32/1457_2.png) [@Bodigrim](https://discourse.haskell.org/u/Bodigrim)\
**Post date:** [December 18, 2023, 12:25am UTC](https://discourse.haskell.org/t/hls-2-5-0-0-is-now-available/8244/14 "2023-12-18T00:25:57Z")

</div>

Everything is possible, someone just has to do it.

---

<div class="post-metadata">

**Author:** ![george.fst](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/george.fst/32/4933_2.png) [@george.fst](https://discourse.haskell.org/u/george.fst)\
**Post date:** [December 18, 2023, 8:47pm UTC](https://discourse.haskell.org/t/hls-2-5-0-0-is-now-available/8244/15 "2023-12-18T20:47:21Z")

</div>

I’m sure it is, but if it were trivial someone would have done it by now. [This issue](https://github.com/haskell/haskell-language-server/issues/1732) might be the best starting point, as I can’t find one that’s specifically about extracting the functionality which previously existed now that Wingman is no more (I feel like it’s been discussed a lot, but maybe it was just at ZuriHac).

---

<div class="post-metadata">

**Author:** ![alanz](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/alanz/32/678_2.png) [@alanz](https://discourse.haskell.org/u/alanz)\
**Post date:** [December 18, 2023, 11:32pm UTC](https://discourse.haskell.org/t/hls-2-5-0-0-is-now-available/8244/16 "2023-12-18T23:32:25Z")

</div>

Wasn’t there a recent rework of the error reporting machinery to make it easier for API users to get the diagnostics before they get printed for display?

---

<div class="post-metadata">

**Author:** ![michaelpj](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/michaelpj/32/417_2.png) [@michaelpj](https://discourse.haskell.org/u/michaelpj)\
**Post date:** [December 19, 2023, 10:34am UTC](https://discourse.haskell.org/t/hls-2-5-0-0-is-now-available/8244/17 "2023-12-19T10:34:14Z")

</div>

HLS hasn’t adapted to the new diagnostics interface yet. It’s a chunk of work for someone to do at some point, good self-contained task for a keen contributor!

---

<div class="post-metadata">

**Author:** ![michaelpj](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/michaelpj/32/417_2.png) [@michaelpj](https://discourse.haskell.org/u/michaelpj)\
**Post date:** [December 19, 2023, 10:37am UTC](https://discourse.haskell.org/t/hls-2-5-0-0-is-now-available/8244/18 "2023-12-19T10:37:56Z")

</div>

> <https://github.com/haskell/haskell-language-server/issues/2014>
>
> Hello folks,
> 
> This is a meta ticket, feel free to close it if you think this i…s not the appropriate place to discuss the subject.
> 
> \_Summary: GHC changed how diagnostics are emitted, HLS can benefit from this, help needed to integrate the work and feedback welcome to improve GHC to best serve HLS.\_
> 
> Well-Typed has been working together with @goldfirere for the past few months on what used to be GHC proposal \[306\](https://github.com/ghc-proposals/ghc-proposals/pull/306), i.e. refactor GHC so that it would emit richer Haskell types instead of \`SDoc\`s for its diagnostic messages. Since the original GHC ticket (cfr. \[ghc#18516\](https://gitlab.haskell.org/ghc/ghc/-/issues/18516)) and the inception of our work, we tried to do our best to keep in mind HLS and Haskell IDEs in general as the primary consumers/beneficiaries of this work. The \[Wiki page\](https://gitlab.haskell.org/ghc/ghc/-/wikis/Errors-as-(structured)-values) goes a bit deeper into the original design work, if people are interested.
> 
> I think we are now at a stage where it would be nice to start thinking how we can collectively integrate this into HLS and what we can learn from this exercise so that we can improve what we have already in GHC before 9.4 (that would be nice but not strictly required, I guess).
> 
> \### 30 seconds overview
> 
> To give you a 30 seconds overview of GHC's \`HEAD\`, we now have a typeclass:
> 
> \`\`\`hs
> class Diagnostic a where
> diagnosticMessage :: a -\> DecoratedSDoc
> diagnosticReason :: a -\> DiagnosticReason
> diagnosticHints :: a -\> \[GhcHint\]
> \`\`\`
> 
> And a bunch of types that implement instances for it, which forms a hierarchy:
> 
> \`\`\`hs
> data GhcMessage where
> -- | A message from the parsing phase.
> GhcPsMessage :: PsMessage -\> GhcMessage
> -- | A message from typecheck/renaming phase.
> GhcTcRnMessage :: TcRnMessage -\> GhcMessage
> -- | A message from the desugaring (HsToCore) phase.
> GhcDsMessage :: DsMessage -\> GhcMessage
> -- | A message from the driver.
> GhcDriverMessage :: DriverMessage -\> GhcMessage
> -- | An \\"escape\\" hatch which can be used when we don't know the source of
> -- the message or if the message is not one of the typed ones. 
> GhcUnknownMessage :: forall a. (Diagnostic a, Typeable a) =\> a -\> GhcMessage
> \`\`\`
> 
> GHC now emits these types (each individually wrapped in a \`MsgEnvelope\` which gives you \`Severity\` and a \`SrcSpan\` amongst other things) which can be "queried" to get not just the pretty-printed message but also the reason why it arose (it will include a\`WarningFlag\` if this is a warning) and a list of \`GhcHint\`. Furthermore, both these types and \`GhcHint\` will include proper information about the diagnostic: for example, if this is a message coming from the type checker about unused pattern binds, GHC will emit a \`TcRnUnusedPatternBinds :: HsBind GhcRn -\> TcRnMessage\` that will give the caller the actual binds, not just a list of \`SDoc\`. The \`GhcHint\` type follows a similar logic, for example GHC might emit \`\[SuggestExtension LangExt.BangPatterns\]\`. 
> 
> \### Little disclaimer
> 
> Currently not all diagnostics have been ported within GHC (due to their sheer amount). For some of those, we still have the old \`SDoc\` wrapped into a constructor (specific to the type of message we want to emit), like, for example a \`TcRnUnknownMessage :: SDoc -\> TcRnMessage\`. Similarly, not all diagnostics have a proper list of hints attached to them, for some not-yet-ported or not-fully-ported, we still have the hints bundled with the pretty-printed message (i.e. the \`diagnosticMessage\`). We are actively working on this.
> 
> \### Where to go from here
> 
> The idea would be for HLS to use this information directly instead of parsing and using regexes on the raw output of the compiler. In a GHC meta-ticket about the "remaining work" (see "Little Disclaimer" section) @wz1000 and @bgamari \[suggested\](https://gitlab.haskell.org/ghc/ghc/-/issues/19905#note\_363751) to look at the \[error parsing logic\](https://github.com/haskell/haskell-language-server/blob/master/ghcide/src/Development/IDE/Plugin/CodeAction.hs) in \`ghcide\` to see if we can get rid of all those "matchRegex" calls and just use the new infrastructure.
> 
> I wanted to have some fun taking a crack at it (as a proof-of-concept, mostly), but it revealed to be harder than I was expecting, mostly due to the perfect storm arising from the changes between GHC 9.2 and 9.3/HEAD (including Alan's work on exactprint) and the changes to \`Data.List\` and its import which broke virtually all the packages I have tried to build. Despite I have used the patched versions of @fendor I have found online, having a working version of \`ghcide\` built with \`HEAD\` was too hard and I have abandoned ship, but I am happy to be told I was doing it all wrong and there is a branch that magically compiles :)
> 
> Having said that, I've started taking a cursory look at the \`CodeAction.hs\` module, and the first thing that stood out was that currently \`ghcide\` is running regexes on the \`\_message\` field on the \`Diagnostic\` type, which comes from \`lsp\`:
> 
> \`\`\`hs
> data Diagnostic =
> Diagnostic
> { \_range :: Range
> , \_severity :: Maybe DiagnosticSeverity
> , \_code :: Maybe (Int |? Text)
> , \_source :: Maybe DiagnosticSource
> , \_message :: Text
> , \_tags :: Maybe (List DiagnosticTag)
> , \_relatedInformation :: Maybe (List DiagnosticRelatedInformation)
> } deriving (Show, Read, Eq, Ord, Generic)
> \`\`\`
> 
> Here \`\_message\` is \`Text\` whereas we would need to be given something more structured. @wz1000 pointed out (in the same GHC 19905 issue) that we can \[change this\](https://gitlab.haskell.org/ghc/ghc/-/issues/19905#note\_364312), but rather than keeping this conversation tucked into the GHC issue tracker, I wanted to share this on this repo to collect feedback and useful pointers on how we could push the work forward. Again, from a super quick look at \`ghcide\` codebase it seems like the \`IdeResult\` type could be changed to return not just a \`Diagnostic\` but a \`GhcMessage\`, which we would get (almost) from free from GHC's \`tcRnModule\` (in \`HEAD\`, that is):
> 
> \`\`\`hs
> tcRnModule :: HscEnv
> -\> ModSummary
> -\> Bool
> -\> HsParsedModule
> -\> IO (Messages TcRnMessage, Maybe TcGblEnv) -- We would need to \`fmap\` GhcTcRnMessage over this.
> \`\`\`
> 
> Therefore, concretely, I guess what I am asking is the following:
> 
> 1. What would be the least painful way to try out whether GHC is solving HLS/ghcide's actual problems? Is
> there some magical fork targeting GHC \`HEAD\` somewhere?
> 
> 2. What would be the required steps to feed \`ghcide\` with structured types instead of a textual \`\_message\`?
> 
> 3. Is there any other place apart form the \`CodeAction.hs\` we should focus or lens on to understand if the GHC work is going into the right direction?
> 
> Thanks in advance! 😉