"Error: Dependency on unbuildable library" with three internal libraries and `--enable-multi-repl`

[nspin]

Describe the bug

Given three internal libraries x, y, and z, where z depends on both x and y, cabal repl --enable-multi-repl x z fails with:

Error: Dependency on unbuildable library 'x' from foo

Modifying y to depend on x causes that cabal repl invocation to succeed.

Here is a concrete foo.cabal to demonstrate:

cabal-version: 3.14

name:           foo
version:        0.1.0.0
build-type:     Simple

library x
  exposed-modules:
      X
  hs-source-dirs:
      components/x
  build-depends:
      base

library y
  exposed-modules:
      Y
  hs-source-dirs:
      components/y
  build-depends:
      base
    -- uncommenting this causes 'cabal repl --enable-multi-repl x z`' to succeed
    -- , foo:x

library z
  exposed-modules:
      Z
  hs-source-dirs:
      components/z
  build-depends:
      base
    , foo:x
    , foo:y

To Reproduce

Run cabal repl --enable-multi-repl x z with the above foo.cabal file.

I've created a repository at https://github.com/nspin/cabal-multi-repl-bug-repro with all the necessary files, instructions, and a Nix shell.

Expected behavior

I would expect this cabal repl invocation to succeed.

System information

• Operating system: NixOS
• cabal, ghc versions: cabal version 3.14.1.0, ghc version 9.8.4

Additional context

Could be related to #6470 from 2019.

[MangoIV]

this also affects hls' multi repl support, it seems to always happen if there's three components and one of them depends on two of the others, so you don't actually need three libraries, two libraries and an executable or test-suite is enough.

[mpickering]

In the x z case, then ./Setup configure is correctly called with

--promised-dependency=foo-0.1.0.0:x=foo-0.1.0.0-inplace-x

likewise in the x y z case, ./Setup configure is correctly called with

--promised-dependency=foo-0.1.0.0:x=foo-0.1.0.0-inplace-x
--promised-dependency=foo-0.1.0.0:y=foo-0.1.0.0-inplace-y

[mpickering]

The problem is the map union when combining together promised and normal dependencies was left biased and dropping the promised dependencies.

[mpickering]

@nspin Thanks for the reproducer, very useful. I have fixed this in #10841 if you wish to test.

@ulysses4ever It would be good to backport this fix if possible.

[ulysses4ever]

@mpickering since it doesn't change the API and fixes an actual bug, I'm all for backporting it. I'll set the label...