Customize the unitId used for the fake internal component

[pepeiborra]

ghcide sets a custom unit id for the internal component. While this is mostly an internal implementation detail, it leaks out when trying to reuse interface files produced by ghc, which will need to be configured with --this-unit-id fake_uid. This is fine, but what if in the future ghcide changes the fake uid string?

This PR adds a flag to control the fake uid string which can be used to get some protection against future ghcide changes.

Additionally, we should probably change the default value to "main", which is the name ghc uses for the default component, in order to make the scenario above, reusing interface files produced by ghc, work out of the box in most cases. Thoughts @fendor @wz1000 ?

[fendor]

LGTM.

I think "main" fake_uid can work, at least I don't know of a blocker from the top of my head.

[pepeiborra]

LGTM.

I think "main" fake_uid can work, at least I don't know of a blocker from the top of my head.

Perfect, let's change it and see what the test suite says

[wz1000]

Can we set the unit id per component? hiedb expects a unique (ModuleName, UnitId) pair which causes some issues with main modules: wz1000/HieDb#13

[fendor]

I remember the unit id was set to the same for each component for a reason. However, writing a test for it and proving that it does or doesn't work is probably the best course of action.

[pepeiborra]

I think the answer is no, see:

haskell-language-server/ghcide/session-loader/Development/IDE/Session.hs

Lines 714 to 717 in 76ea473

	-- There are several places in GHC (for example the call to hptInstances in
	-- tcRnImports) which assume that all modules in the HPT have the same unit
	-- ID. Therefore we create a fake one and give them all the same unit id.
	removeInplacePackages

[wz1000]

OK. However, this change will mean that the hiedb database will have a lot of duplicate/redundant keys which will show up in queries. I think we will need to write a migration script for this - the easiest thing to do would be to just delete all the modules from "fake_uid", and letting ghcide take care of re-indexing. Another easy change could be to just bump sCHEMA_VERSION in hiedb, which will force ghcide to delete the old database and re-index everything.

See https://github.com/wz1000/HieDb/blob/62e24fb2b10ed17fadb0b1c69fc1067b6fc2984e/src/HieDb/Create.hs#L264 and https://github.com/wz1000/HieDb/blob/62e24fb2b10ed17fadb0b1c69fc1067b6fc2984e/src/HieDb/Create.hs#L38 respectively.

[pepeiborra]

How about adding a version number to the path computed by getHieDbLoc? The old database will stay around, but that's not a bad thing - it will still work for HLS 1.0.0.0

[pepeiborra]

@wz1000 I have added the version number to the hiedb path