| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This large commit combines several interrelated changes:
- IfaceSyn now contains actual Names rather than the special
IfaceExtName type. The binary interface file contains
a symbol table of Names, where each entry is a (package,
ModuleName, OccName) triple. Names in the IfaceSyn point
to entries in the symbol table.
This reduces the size of interface files, which should
hopefully improve performance (not measured yet).
The toIfaceXXX functions now do not need to pass around
a function from Name -> IfaceExtName, which makes that
code simpler.
- Names now do not point directly to their parents, and the
nameParent operation has gone away. It turned out to be hard to
keep this information consistent in practice, and the parent info
was only valid in some Names. Instead we made the following
changes:
* ImportAvails contains a new field
imp_parent :: NameEnv AvailInfo
which gives the family info for any Name in scope, and
is used by the renamer when renaming export lists, amongst
other things. This info is thrown away after renaming.
* The mi_ver_fn field of ModIface now maps to
(OccName,Version) instead of just Version, where the
OccName is the parent name. This mapping is used when
constructing the usage info for dependent modules.
There may be entries in mi_ver_fn for things that are not in
scope, whereas imp_parent only deals with in-scope things.
* The md_exports field of ModDetails now contains
[AvailInfo] rather than NameSet. This gives us
family info for the exported names of a module.
Also:
- ifaceDeclSubBinders moved to IfaceSyn (seems like the
right place for it).
- heavily refactored renaming of import/export lists.
- Unfortunately external core is now broken, as it relied on
IfaceSyn. It requires some attention.
|
|
|
Most of the other users of the fptools build system have migrated to
Cabal, and with the move to darcs we can now flatten the source tree
without losing history, so here goes.
The main change is that the ghc/ subdir is gone, and most of what it
contained is now at the top level. The build system now makes no
pretense at being multi-project, it is just the GHC build system.
No doubt this will break many things, and there will be a period of
instability while we fix the dependencies. A straightforward build
should work, but I haven't yet fixed binary/source distributions.
Changes to the Building Guide will follow, too.
|
