Move loadDecl into IfaceToCore

1 files changed, 5 insertions, 4 deletions

diff --git a/compiler/GHC/Iface/Syntax.hs b/compiler/GHC/Iface/Syntax.hs
index 72ff681c99..e6fc3a8bc0 100644
--- a/compiler/GHC/Iface/Syntax.hs
+++ b/compiler/GHC/Iface/Syntax.hs
@@ -469,7 +469,8 @@ ifaceDeclImplicitBndrs :: IfaceDecl -> [OccName]
 -- N.B. the set of names returned here *must* match the set of
 -- TyThings returned by GHC.Driver.Env.implicitTyThings, in the sense that
 -- TyThing.getOccName should define a bijection between the two lists.
--- This invariant is used in GHC.Iface.Load.loadDecl (see note [Tricky iface loop])
+-- This invariant is used in GHC.IfaceToCore.tc_iface_decl_fingerprint (see note
+-- [Tricky iface loop])
 -- The order of the list does not matter.
 
 ifaceDeclImplicitBndrs (IfaceData {ifName = tc_name, ifCons = cons })
@@ -2017,13 +2018,13 @@ knot in the type checker. It saved ~1% of the total build time of GHC.
 When we read an interface file, we extend the PTE, a mapping of Names
 to TyThings, with the declarations we have read. The extension of the
 PTE is strict in the Names, but not in the TyThings themselves.
-GHC.Iface.Load.loadDecl calculates the list of (Name, TyThing) bindings to
-add to the PTE. For an IfaceId, there's just one binding to add; and
+GHC.IfaceToCore.tcIfaceDecls calculates the list of (Name, TyThing) bindings
+to add to the PTE.  For an IfaceId, there's just one binding to add; and
 the ty, details, and idinfo fields of an IfaceId are used only in the
 TyThing. So by reading those fields lazily we may be able to save the
 work of ever having to deserialize them (into IfaceType, etc.).
 
-For IfaceData and IfaceClass, loadDecl creates extra implicit bindings
+For IfaceData and IfaceClass, tcIfaceDecls creates extra implicit bindings
 (the constructors and field selectors of the data declaration, or the
 methods of the class), whose Names depend on more than just the Name
 of the type constructor or class itself. So deserializing them lazily