#5306: Data family constructor imports broken
---------------------------------+------------------------------------------
Reporter: reinerp | Owner: simonpj
Type: bug | Status: new
Priority: normal | Milestone: 7.4.1
Component: Compiler | Version: 7.0.3
Keywords: type families | Testcase:
Blockedby: | Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: GHC rejects valid program
---------------------------------+------------------------------------------
Comment(by simonpj@…):
commit fe44af73d58839e3010e1234cece0dd6c33f7eb5
{{{
Author: Simon Peyton Jones <[email protected]>
Date: Tue Aug 2 10:43:57 2011 +0100
Change the representation of export lists in .hi files
Currently export list in .hi files are partitioned by module
export M T(C1,C2)
N f,g
In each list we only have OccNames, all assumed to come from
the parent module M or N resp.
This patch changes the representatation so that export lists
have full Names:
export M.T(M.C1,M.C2), N.f, N.g
Numerous advatages
* AvailInfo no longer needs to be parameterised; it always
contains Names
* Fixes Trac #5306. This was the main provocation
* Less to-and-fro conversion when reading interface files
It's all generally simpler. Interface files should not get bigger,
becuase they have a nice compact representation for Names.
compiler/basicTypes/Name.lhs | 22 +++++-
compiler/iface/BinIface.hs | 2 +-
compiler/iface/IfaceEnv.lhs | 20 +-----
compiler/iface/LoadIface.lhs | 21 ++---
compiler/iface/MkIface.lhs | 55 ++-----------
compiler/main/HscTypes.lhs | 50 +++++++-----
compiler/prelude/PrelInfo.lhs | 23 +++---
compiler/rename/RnEnv.lhs | 12 +--
compiler/rename/RnNames.lhs | 174
+++++++++++++++++++----------------------
compiler/rename/RnSource.lhs | 2 +-
10 files changed, 167 insertions(+), 214 deletions(-)
}}}
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5306#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
