search

fpco / ide-backend

ide-backend drives the GHC API to build, query, and run your code
120 stars 17 forks source link

Package hiding/unhiding still not completely stateless? #257

Open edsko opened 10 years ago

edsko commented 10 years ago

When running tests in parallel, occasionally we get test failures about hidding packages, which are not getting if we run the tests strictly sequentially (but with session reuse).

Unexpected errors: SourceError {errorKind = KindError, errorSpan = Baz.hs@4:1-4:35, errorMsg = "Failed to load interface for `Control.Parallel'\nIt is a member of the hidden package `parallel-3.2.0.4'."}

I don't understand why this should be the case -- surely hiding or unhiding packages should be local to the ghc session? Would either ghc or cabal change the visibility of packages in the global package DB?

dcoutts commented 10 years ago

No, neither Cabal nor ghc make persistent changes to the visibility of packages in the database. GHC itself only ever reads package dbs (it does not have code to write them). Cabal only registers packages, it does not modify existing ones.

edsko commented 10 years ago

In that case this must mean we still don't completely manage to reset ghc state correctly, though I don't know how or when. We have explicit tests for hiding and unhiding packages, as well as setting and unsetting -hide-all-packages, so I'm not sure what's going on here.

mgsloan commented 9 years ago

This is affecting the travis builds - see https://travis-ci.org/fpco/ide-backend/jobs/74153359#L554

I suspect the fix for #224 needs to be revisited.

For now I'm going to have the test always use --no-session-reuse. Yuck!