Ambiguity problem with re-exports and multiple packages

[mrBliss]

To reproduce the problem:

• Clone https://github.com/mrBliss/ghcide-bug.
  This repo consists of three packages: a, b, and c.

  b depends on a, and c depends on both a and b.

  Each package contains a single module: A.hs, B.hs, and C.hs respectively.

  • A.hs defines and exports data Foo = Foo
  • B.hs re-exports A
  • C.hs imports both A and B and defines a value foo :: Foo. Important: both A and B export this same Foo type.

  This repo has a multi-component hie.yaml that uses cabal for building.

• Open C.hs and start ghcide for the entire ghcide-bug project (not just the c cabal package).

• Now open A.hs while C.hs is still open in your editor (and thus ghcide session).

• Now go back to C.hs, suddenly you get an error:

  typecheck: Ambiguous occurrence ‘Foo’
  It could refer to either ‘Foo’,
                           imported from ‘A’ at C.hs:3:1-8
                           (and originally defined
                              at A.hs:3:1-14)
                        or ‘Foo’,
                           imported from ‘B’ at C.hs:4:1-8
                           (and originally defined in ‘A’)
  

  It seems that by opening A.hs, Foo appears to get reloaded in the ghcide session. However, the b package is somehow not properly reloaded, so that it still exports the old version of Foo. Now two versions of Foo are in scope in C.hs.

This makes it impossible for me to use ghcide in a downstream package while at the same time opening a module from an upstream package.

My setup:

• ghcide: haskell/ghcide@ceb9eb7
• GHC 8.6.5
• Emacs 27.1 + lsp-mode

[mrBliss]

@jneira Why the "needs repro" label? I think the minimal example in the description is a repro, right?

[ndmitchell]

@mrBliss - I think it's because we need a second person to confirm it reproduces and thus isn't a weird quirk of some cabal/GHC setting you modified on your machine a long time ago. Agreed, your bug report seems quite extensive - thanks for taking the time to produce something so clear!

[mrBliss]

@mrBliss - I think it's because we need a second person to confirm it reproduces and thus isn't a weird quirk of some cabal/GHC setting you modified on your machine a long time ago. Agreed, your bug report seems quite extensive - thanks for taking the time to produce something so clear!

Ah, alright, gotcha.

[fendor]

IIRC I reproduced exactly this issue a couple of days ago.
I think this is a regression and was fixed in the very early days of multi-component.

[jneira]

@mrBliss: @ndmitchell is right, sorry if the label sounds a little bit harsh, the description is "It needs to be reproduced by someone else" but it is not shown by default

EDIT: i've created another tag needs alternative repro to be more precise

[pepeiborra]

How is this different from the known issue outlined in the README:

There is a known issue where if you have three components, such that A depends on B which depends on C then if you load A and C into the session but not B then under certain situations you can get strange errors about a type coming from two different places. See this repo for a simple reproduction of the bug.

[mrBliss]

How is this different from the known issue outlined in the README:

There is a known issue where if you have three components, such that A depends on B which depends on C then if you load A and C into the session but not B then under certain situations you can get strange errors about a type coming from two different places. See this repo for a simple reproduction of the bug.

Aha, that indeed sounds like exactly the same issue! Sorry for missing that 😳. Is there an existing issue I could have commented on and that is used to track the progress on it?

Nevertheless, I would still appreciate very much if it were fixed, because I can't use ghcide for my day job because of this.

(If I use a direct cradle, I run into https://github.com/haskell/ghcide/issues/842, I believe.)

[pepeiborra]

I don't know how to fix this, in the current state of affairs. The notes I left in haskell/ghcide#842 might provide some clarity

The only workaround I know is to use a direct cradle to manually merge both components into a single one, which is not trivial. I don't see why you would run into haskell/ghcide#842 if the direct cradle is properly constructed.

[ocharles]

Ahh, I'm really glad to see someone has reported this! I keep running into this myself in our work code base. For example, right now I see this:

(Sorry about the screenshot, I'm not sure how to actually copy/paste errors out of Emacs popups!)

I just want to confirm this bug. I'm using a completely implicit cradle (no hie.yaml at all)

Edit: Or perhaps mine is a different bug, because mine talks about fake_uid and ch-model packages? I have no idea what fake_uid is, it's nothing I have written.

[pepeiborra]

It's the same bug, fake_uid is the name of the fake package that ghcide creates and loads in the GHC session. We should probably improve the name to give some clarity.

I don't know that anyone is actively working on fixing this (/cc @wz1000) so your best bet is to craft a direct/bios cradle that merges all your packages into a single project. Tooling to automate this (in the style of implicit-hie) might be the best way to fix this issue.

[mrBliss]

Ahh, I'm really glad to see someone has reported this! I keep running into this myself in our work code base. For example, right now I see this:
[..]

@ocharles I'm also glad to hear I'm not the only one suffering from this!

The only workaround I know is to use a direct cradle to manually merge both components into a single one, which is not trivial. I don't see why you would run into haskell/ghcide#842 if the direct cradle is properly constructed.

Right, back to the direct cradle for now. I'm pretty sure my direct cradle definition is correct: it has worked fine for months with an older version (pre 0.2.0) of ghcide and hie-bios check <MODULE> works as expected.

I just found out some more circumstances related to the error from haskell/ghcide#842 that I'm getting:

• As mentioned already: there have to be multiple packages in play (although merged in a direct cradle) and some files from multiple packages have to have been opened in the same session.
• There is a cache hit in .cache/ghcide when loading a module in ghcide
• Boom, the error from haskell/ghcide#842.
• The error goes away when removing the cache and restarting. I haven't yet been able to reliably produce it all, though.

I suspect that the problem has something to do with the cached .hi or .hie files containing names with different IDs than the one already loaded in the session.

[pepeiborra]

Does your direct cradle list all the targets in your cumulative set of projects? See the hie-bios readme for more info.

This wasn't a requirement in ghcide 0.2.0 but it is a requirement now.