hs-boot knot tying insufficient for ghc --make
GHC in one-shot mode goes through great pains to make sure that if we are typechecking A.hs with an A.hs-boot, any references to A in the interfaces we load in should point to the TyThing
s from our LOCAL tcg_type_env
(_var
), not the declarations from the hs-boot
. Indeed, it is never right to load the hi-boot file into the EPS (#10182 (closed), #10336). Because in one-shot compilation we are loading things into the EPS anew, there is not much risk of having stale TyThing
s lying around which still refer to the old hs-boot
ModDetails.
ghc --make
does not do a sufficient job as knot tying. Specifically, any Id
s/TyThing
s from the HPT which were built against the hs-boot
ModDetails will have out-of-date information. We do manage to tie the knot if we use tcLookupGlobal
directly, which does look in the local type environment (e.g., #12034 affects both -c
and --make
), but if we get our hands on a TyThing
indirectly, we're in trouble. The case where this is most obvious is unfoldings; see #10083 (closed) for an example of GHC behaving differently between -c
and --make
(although, ironically, --make
s bad behavior masks the bug).
It's not entirely clear how to fix this problem. In analogy to what happens in -c
, we should clear the stale TyThing
s from our HPT and retypecheck them after we have setup the type environment for our hs
file. But presently in --make
we don't lazily load types from our home package. Maybe we should!
Trac metadata
Trac field | Value |
---|---|
Version | 8.1 |
Type | Bug |
TypeOfFailure | OtherFailure |
Priority | normal |
Resolution | Unresolved |
Component | Compiler (Type checker) |
Test case | |
Differential revisions | |
BlockedBy | |
Related | |
Blocking | |
CC | |
Operating system | |
Architecture |