ghcide master?

[alanz]

A lot has happened since Bristol, and we have made a lot of progress, in ghcide and hls.

In the hls world, there was a time when ghcide did not have multi-cradle support, and had some performance issues, so we used a separate fork. This had some major differences, driven primarily by the alternate build process put forward by @mpickering.

My understanding is that the issues in ghcide have largely been resolved, and it is settling in as the primary development point for "vanilla GHC" features. This makes sense.

But hls is still running a fork of ghcide that is a long way from ghcide master.

Is there still any reason to do this? I would personally prefer the gap to be as small as possible, so we can proceed as two parts of one project, each addressing a different constituency.

[alanz]

Ping @wz1000 @fendor @pepeiborra @cocreature @mpickering @jneira

[alanz]

Left out (at least) @ndmitchell
Sorry to any others, not intentional.

[jneira]

Well, to summarize the alternatives as i see them:

• We could continue in the bleeding edge, offering more powerful features with @wz1000 hiedb fork + @mpickering newest one.
  • Exposing users to possible bugs and maybe alienating them in exchange
• Or move to the stable side of things and focus on the plugin arquitecture and plugins.

Maybe a combination of both would be possible, jump to stable right now and return later to the actual state.
Not sure if we could make progresses in two fronts simultaneously.

[wz1000]

We are running on hls-2, which is ghcide head plus some changes we intend to upstream. These changes aren't too major, they mainly consist of

1. This PR: Use stale information if it's available to answer requests quickly ghcide#624
2. A backport of .hie files to ghc 8.6
3. A rewrite of definition/typedefinition/hover using .hie files
4. documentSymbols using .hie files
5. A module graph
6. Propagating changes to parent modules on save using the module graph
7. @bubba's patch to add hyperlinks to hover
8. Initial support for telemetry thanks to @mpardalos

I prefer it this way as we have a proving ground for changes before they make their way into ghcide master. Most of these changes are pretty stable by this point, since they have been included in Matthew's hls branch for some time.

The hiedb changes are not included because I don't think they are ready yet.

[pepeiborra]

Testing future ghcide changes on hls users seems to me a recipe for hls maintenance headaches. I'm unconvinced that this is a good argument. To prove my ghcide major changes, I have been following this methodology:

1. Testing them by using a dev build of ghcide on the ghcide codebase as well as on the (non public) Strats codebase
2. Building up the testing and benchmarking infrastructure in ghcide.

As a ghcide contributor, I hope that all the good stuff in the hls-2 fork will be upstreamed asap.

[ndmitchell]

I find it really weird that ghcide master is not the place for cutting edge development of ghcide. In fact, I don't really even know where is, which prevents me as a contributor for doing much beyond tinkering around the edges.

The fact that we are encouraging people to use a version of ghcide which doesn't have a home is confusing - it's hard to know how to report issues and every time someone says something about Ghcide you have to clarify which Ghcide they are using. It adds to the support burden.

Like @pepeiborra I'm a big fan of getting all the stuff in hls-2 upstream and then use ghcide HEAD as the cutting edge and ghcide Hackage as the last-stable version.

[wz1000]

I agree that we should switch to ghcide master once everything in hls-2 has been upstreamed.

[pepeiborra]

What's the reason for not migrating now ?

[ndmitchell]

I crated https://github.com/digital-asset/ghcide/issues/663 to track the things that need upstreaming.

[wz1000]

hls-2 has quite a few behavioral changes compared to master, like typechecking parent modules on save, supporting the document symbols LSP request and so on.

These features have been included in haskell-language-server for a long time now, almost two months. I don't see the benefit of regressing in features, when the hls-2 branch is up to date with the latest ghcide.

[pepeiborra]

Document symbols are supported in ghcide too, and type checking parent modules as well.

What other behavioural changes are there?

[wz1000]

Sorry, I meant documentHighlight instead of documentSymbol.

type checking parent modules as well.

where is this?

[pepeiborra]

kick typechecks all the files of interest and their parents, assuming that by parents you mean dependencies

[wz1000]

By parents I mean reverse dependencies (i.e. files that depend on the current module), even those that are not files of interest.

[alanz]

HaRe calls them client modules, ones that make use of a given module. And for this you need the module graph.

[lukel97]

On the topic of this are there any plans to unify the exe/Main.hs executable components between ghcide and hls? There's a lot of duplicated logic going on here, and it's pretty important logic too relating to cradle and session setup.

[alanz]

On the topic of this are there any plans to unify the exe/Main.hs executable components between ghcide and hls?

See https://github.com/digital-asset/ghcide/issues/478

[jneira]

It had been some merged prs upstream and we have now hls-3, so this should be a litle bit close to get done

[jneira]

• hls and master had been merged and we could use ghcide master here