#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