[GHC] #12485: -package-db flags now need to be sorted by dependency order

[GHC]

#12485: -package-db flags now need to be sorted by dependency order
-------------------------------------+-------------------------------------
        Reporter:  niteria           |                Owner:
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:  8.0.3
       Component:  Package system    |              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:D2450,
       Wiki Page:                    |  phab:D2514
-------------------------------------+-------------------------------------

Comment (by ezyang):

 > In the short term, would anything go wrong if we allowed an IPID
 anywhere in the stack to satisfy a dependency provided it was unique? And
 if a dependency is not unique, we resolve in the current way, using the DB
 ordering.

 OK, while I was implementing this, I discovered a fairly nasty edge case.
 Consider:

 * db1: p (depends on q)
 * db2: q (depends on r from db3)
 * db3: r
 * db4: r (shadows r from db3)

 A "proper" order to specify these databases is db3 db2 db1 db4, which
 would have the net effect of only bringing r into scope (since everything
 else gets killed with db3's r gets shadowed.) Alternately, db4 db3 db2 db1
 would see just db4 be killed.

 What do you expect to happen if the databases are specified: `db1 db3 db4
 db2`? Under the "non-duplicated package can be specified anywhere" rule,
 `db1` is OK because it refers to `q`, which indeed is only mentioned once.

 OK, now the nastiness begins. Remember that we still need to process
 shadowing in order. So we accept `db1`, process `db3` (fine), and then
 process `db4`, at which point there is a problem. The r from db4 needs to
 shadow the db3 r, and invalidate anything that depends on it. This
 *somehow* has to include db1 and db4, but we haven't even "gotten" to db4
 to process it yet. A giant mess!

 I don't really care about trying hard to salvage the situation, if a user
 comes into it. But what I do care about is giving an easily interpretable
 explanation about whatever behavior we do. But it doesn't seem like there
 is reasonable "non-magical" semantics I can give for this case.

 Here's an alternative: what if we allow you to order your `-package-db`
 flags however you want, but ONLY if there is NO shadowing anywhere in the
 stack? In that case, matters are simple. I am only a little less
 enthusiastic about this because you only need to have one case of
 irrelevant shadowing and boom your command line stops working. Guidance
 requested! What do you care about?

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12485#comment:27>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler