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.
@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.
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.
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.
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.
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.
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.
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.
I’m sure it is, but if it were trivial someone would have done it by now. This issue 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).
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?
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!