#13313: cabal08 broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): How did it break? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13313#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#13313: cabal08 broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed I can reliably reproduce this. I've marked the test as broken in 8ccbc2e5252abd4fa67d155d4fff489ee9929906. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13313#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#13313: cabal08 broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: ezyang Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): Yes, I've diagnosed the problem. The trouble is that the new algorithm for computing package shadowing doesn't remember the order packages were specified in package databases, so it doesn't respect the flag ordering; instead, it relies entirely on the (deterministic) comparison of unit identifiers. Probably the reason why this wobbled is because Cabal was allocating different unit identifiers on different platforms, causing the (deterministic) comparison to wobble, so that we picked one or another. It would be very good to fix this in time for GHC 8.2. However, fixing this seems a bit annoying in the current algorithm, because there isn't really a good way to remember the package ordering after we suck all the packages into an InstalledPackageIndex. I'll work on a fix this weekend. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13313#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#13313: cabal08 broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: ezyang Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3369 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang <ezyang@…>): In [changeset:"e0eaea918c32b3aa445708656876d1e2aef94a13/ghc" e0eaea91/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e0eaea918c32b3aa445708656876d1e2aef94a13" Correctly account for -package-db ordering when picking packages. Summary: When I originally implemented ABI-based shadowing as per ee4e1654c31b9c6f6ad9b19ece25f040bbbcbd72, I switched our strategy from pasting together lists to creating a map of all units first, and then selecting packages from this. However, what I did not realize when doing this was that we actually depended on the *ordering* of these lists later, when we selected a preferred package to use. The crux is if I have -package-db db1 -package-db db2 -package p-0.1, and p-0.1 is provided by both db1 and db2, which one does the -package flag select? Previously, this was undetermined; now we always select the instance from the LATEST package database. (If p-0.1 shows up multiple times in the same database, once again the chosen package is undefined.) The reason why cabal08 intermittently failed was that, in practice, we were sorting on the UnitId, so when we bumped version numbers, that often wibbled the UnitIds so that they compared oppositely. I've extended the test so that we check that the relation is antisymmetric. Fixes #13313 Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: bgamari, austin Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3369 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13313#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler