[GHC] #13313: cabal08 broken

[GHC]

#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 at 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