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 TyThings 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 TyThings lying around which still refer to the old hs-boot ModDetails.

ghc --make does not do a sufficient job as knot tying. Specifically, any Ids/TyThings 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, --makes 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 TyThings 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