1. 30 Oct, 2015 1 commit
    • Simon Peyton Jones's avatar
      Fix unused-import stuff in a better way · 9376249b
      Simon Peyton Jones authored
      The fix for Trac #10890 in commit 1818b48e, namely
         Fix incorrect import warnings when methods with identical names are imported
      was wrong, as demonstrated by the new test T10890_2.  It suppressed
      far too many warnings!
      
      This patch fixes the original problem in a different way, by making
      RdrName.greUsedRdrName a bit cleverer.
      
      But this too is not really the Right Thing.  I think the Right Thing is
      to store the /GRE/ in the tcg_used_rdrnames, not the /RdrName/.  That
      would be a lot simpler and more direct.
      
      But one step at a time.
      9376249b
  2. 16 Oct, 2015 1 commit
    • Adam Gundry's avatar
      Implement DuplicateRecordFields · b1884b0e
      Adam Gundry authored
      This implements DuplicateRecordFields, the first part of the
      OverloadedRecordFields extension, as described at
      https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/DuplicateRecordFields
      
      This includes fairly wide-ranging changes in order to allow multiple
      records within the same module to use the same field names.  Note that
      it does *not* allow record selector functions to be used if they are
      ambiguous, and it does not have any form of type-based disambiguation
      for selectors (but it does for updates). Subsequent parts will make
      overloading selectors possible using orthogonal extensions, as
      described on the wiki pages.  This part touches quite a lot of the
      codebase, and requires changes to several GHC API datatypes in order
      to distinguish between field labels (which may be overloaded) and
      selector function names (which are always unique).
      
      The Haddock submodule has been adapted to compile with the GHC API
      changes, but it will need further work to properly support modules
      that use the DuplicateRecordFields extension.
      
      Test Plan: New tests added in testsuite/tests/overloadedrecflds; these
      will be extended once the other parts are implemented.
      
      Reviewers: goldfire, bgamari, simonpj, austin
      
      Subscribers: sjcjoosten, haggholm, mpickering, bgamari, tibbe, thomie,
      goldfire
      
      Differential Revision: https://phabricator.haskell.org/D761
      b1884b0e
  3. 15 Oct, 2015 1 commit
  4. 03 Jun, 2015 2 commits
  5. 01 Jun, 2015 1 commit
    • Simon Peyton Jones's avatar
      Refactor the GlobalRdrEnv, fixing #7672 · 9b73cb16
      Simon Peyton Jones authored
      This patch started innocently enough, by deleting a single
      call from rnImportDecl, namely
      
          let gbl_env = mkGlobalRdrEnv (filterOut from_this_mod gres)
      
      The 'filterOut' makes no sense, and was the cause of #7672.
      
      But that little loose end led to into a twisty maze of little
      passages, all alike, which has taken me an unreasonably long
      time to straighten out. Happily, I think the result is really
      much better.
      
      In particular:
      
       * INVARIANT 1 of the GlobalRdrEnv type was simply not true:
         we had multiple GlobalRdrElts in a list with the same
         gre_name field. This kludgily implmented one form of
         shadowing.
      
       * Meanwhile, extendGlobalRdrEnvRn implemented a second form of
         shadowing, by deleting stuff from the GlobalRdrEnv.
      
       * In turn, much of this shadowing stuff depended on the Names of
         the Ids bound in the GHCi InteractiveContext being Internal
         names, even though the TyCons and suchlike all had External
         Names. Very confusing.
      
      So I have made the following changes
      
       * I re-established INVARIANT 1 of GlobalRdrEnv.  As a result
         some strange code in RdrName.pickGREs goes away.
      
       * RnNames.extendGlobalRdrEnvRn now makes one call to deal with
         shadowing, where necessary, and another to extend the
         environment.  It deals separately with duplicate bindings.
      
         The very complicated RdrName.extendGlobalRdrEnv becomes much
         simpler; we need to export the shadowing function, now called
         RdrName.shadowNames; and we can nuke
         RdrName.findLocalDupsRdrEnv altogether.
      
         RdrName Note [GlobalRdrEnv shadowing] summarises the shadowing
         story
      
       * The Names of the Ids bound in the GHCi interactive context are
         now all External.  See Note [Interactively-bound Ids in GHCi]
         in HscTypes.
      
       * Names for Ids created by the debugger are now made by
         IfaceEnv.newInteractiveBinder.  This fixes a lurking bug which
         was that the debugger was using mkNewUniqueSupply 'I' to make
         uniques, which does NOT guarantee a fresh supply of uniques on
         successive calls.
      
       * Note [Template Haskell ambiguity] in RnEnv shows that one TH-related
         error is reported lazily (on occurrences) when it might be better
         reported when extending the environment.  In some (but not all) cases
         this was done before; but now it's uniformly at occurrences.  In
         some ways it'd be better to report when extending the environment,
         but it's a tiresome test and the error is rare, so I'm leaving it
         at the lookup site for now, with the above Note.
      
       * A small thing: RnNames.greAvail becomes RdrName.availFromGRE, where
         it joins the dual RdrName.gresFromAvail.
      9b73cb16
  6. 18 May, 2015 1 commit
    • Simon Peyton Jones's avatar
      Refactor tuple constraints · ffc21506
      Simon Peyton Jones authored
      Make tuple constraints be handled by a perfectly ordinary
      type class, with the component constraints being the
      superclasses:
          class (c1, c2) => (c2, c2)
      
      This change was provoked by
      
        #10359  inability to re-use a given tuple
                constraint as a whole
      
        #9858   confusion between term tuples
                and constraint tuples
      
      but it's generally a very nice simplification. We get rid of
       -  In Type, the TuplePred constructor of PredTree,
          and all the code that dealt with TuplePreds
       -  In TcEvidence, the constructors EvTupleMk, EvTupleSel
      
      See Note [How tuples work] in TysWiredIn.
      
      Of course, nothing is ever entirely simple. This one
      proved quite fiddly.
      
      - I did quite a bit of renaming, which makes this patch
        touch a lot of modules. In partiuclar tupleCon -> tupleDataCon.
      
      - I made constraint tuples known-key rather than wired-in.
        This is different to boxed/unboxed tuples, but it proved
        awkward to have all the superclass selectors wired-in.
        Easier just to use the standard mechanims.
      
      - While I was fiddling with known-key names, I split the TH Name
        definitions out of DsMeta into a new module THNames.  That meant
        that the known-key names can all be gathered in PrelInfo, without
        causing module loops.
      
      - I found that the parser was parsing an import item like
            T( .. )
        as a *data constructor* T, and then using setRdrNameSpace to
        fix it.  Stupid!  So I changed the parser to parse a *type
        constructor* T, which means less use of setRdrNameSpace.
      
        I also improved setRdrNameSpace to behave better on Exact Names.
        Largely on priciple; I don't think it matters a lot.
      
      - When compiling a data type declaration for a wired-in thing like
        tuples (,), or lists, we don't really need to look at the
        declaration.  We have the wired-in thing!  And not doing so avoids
        having to line up the uniques for data constructor workers etc.
        See Note [Declarations for wired-in things]
      
      - I found that FunDeps.oclose wasn't taking superclasses into
        account; easily fixed.
      
      - Some error message refactoring for invalid constraints in TcValidity
      
      - Haddock needs to absorb the change too; so there is a submodule update
      ffc21506
  7. 14 May, 2015 1 commit
  8. 13 May, 2015 1 commit
    • Simon Peyton Jones's avatar
      Refactor tuple constraints · 130e93aa
      Simon Peyton Jones authored
      Make tuple constraints be handled by a perfectly ordinary
      type class, with the component constraints being the
      superclasses:
          class (c1, c2) => (c2, c2)
      
      This change was provoked by
      
        #10359  inability to re-use a given tuple
                constraint as a whole
      
        #9858   confusion between term tuples
                and constraint tuples
      
      but it's generally a very nice simplification. We get rid of
       -  In Type, the TuplePred constructor of PredTree,
          and all the code that dealt with TuplePreds
       -  In TcEvidence, the constructors EvTupleMk, EvTupleSel
      
      See Note [How tuples work] in TysWiredIn.
      
      Of course, nothing is ever entirely simple. This one
      proved quite fiddly.
      
      - I did quite a bit of renaming, which makes this patch
        touch a lot of modules. In partiuclar tupleCon -> tupleDataCon.
      
      - I made constraint tuples known-key rather than wired-in.
        This is different to boxed/unboxed tuples, but it proved
        awkward to have all the superclass selectors wired-in.
        Easier just to use the standard mechanims.
      
      - While I was fiddling with known-key names, I split the TH Name
        definitions out of DsMeta into a new module THNames.  That meant
        that the known-key names can all be gathered in PrelInfo, without
        causing module loops.
      
      - I found that the parser was parsing an import item like
            T( .. )
        as a *data constructor* T, and then using setRdrNameSpace to
        fix it.  Stupid!  So I changed the parser to parse a *type
        constructor* T, which means less use of setRdrNameSpace.
      
        I also improved setRdrNameSpace to behave better on Exact Names.
        Largely on priciple; I don't think it matters a lot.
      
      - When compiling a data type declaration for a wired-in thing like
        tuples (,), or lists, we don't really need to look at the
        declaration.  We have the wired-in thing!  And not doing so avoids
        having to line up the uniques for data constructor workers etc.
        See Note [Declarations for wired-in things]
      
      - I found that FunDeps.oclose wasn't taking superclasses into
        account; easily fixed.
      
      - Some error message refactoring for invalid constraints in TcValidity
      130e93aa
  9. 19 Jan, 2015 1 commit
    • Alan Zimmerman's avatar
      API Annotations documentation update, parsing issue, add example test · 851ed721
      Alan Zimmerman authored
      Summary:
      Add a reference note to each AnnKeywordId haddock comment so GHC
      developers will have an idea why they are there.
      
      Add a new test to ghc-api/annotations to serve as a template for other
      GHC developers when they need to update the parser. It provides output
      which checks that each SrcSpan that an annotation is attached to
      actually appears in the `ParsedSource`, and lists the individual
      annotations. The idea is that a developer writes a version of this
      which parses a sample file using whatever syntax is changed in
      Parser.y, and can then check that all the annotations come through.
      
      Depends on D538
      
      Test Plan: ./validate
      
      Reviewers: simonpj, hvr, austin
      
      Reviewed By: austin
      
      Subscribers: thomie, jstolarek
      
      Differential Revision: https://phabricator.haskell.org/D620
      851ed721
  10. 16 Jan, 2015 1 commit
    • Alan Zimmerman's avatar
      API Annotations tweaks. · 11881ec6
      Alan Zimmerman authored
      Summary:
      HsTyLit now has SourceText
      
      Update documentation of HsSyn to reflect which annotations are attached to which element.
      
      Ensure that the parser always keeps HsSCC and HsTickPragma values, to
      be ignored in the desugar phase if not needed
      
      Bringing in SourceText for pragmas
      
      Add Location in NPlusKPat
      
      Add Location in FunDep
      
      Make RecCon payload Located
      
      Explicitly add AnnVal to RdrName where it is compound
      
      Add Location in IPBind
      
      Add Location to name in IEThingAbs
      
      Add Maybe (Located id,Bool) to Match to track fun_id,infix
        This includes converting Match into a record and adding a note about why
        the fun_id needs to be replicated in the Match.
      
      Add Location in KindedTyVar
      
      Sort out semi-colons for parsing
      
        - import statements
        - stmts
        - decls
        - decls_cls
        - decls_inst
      
      This updates the haddock submodule.
      
      Test Plan: ./validate
      
      Reviewers: hvr, austin, goldfire, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D538
      11881ec6
  11. 03 Dec, 2014 1 commit
  12. 28 Nov, 2014 1 commit
    • Simon Peyton Jones's avatar
      Rename some of the functions in NameSet, to make the uniform with VarSet etc · 7460dafa
      Simon Peyton Jones authored
      For ages NameSet has used different names,
        eg.   addOneToNameSet   rather than    extendNameSet
              nameSetToList     rather than    nameSetElems
      
      etc.  Other set-like modules use uniform naming conventions.
      This patch makes NameSet follow suit.
      
      No change in behaviour; this is just renaming.
      
      I'm doing this just before the fork so that merging is easier.
      7460dafa
  13. 12 Nov, 2014 1 commit
    • eir@cis.upenn.edu's avatar
      Fix #9066. · d782694f
      eir@cis.upenn.edu authored
      When splicing in a fixity declaration, look for both term-level things
      and type-level things. This requires some changes elsewhere in the
      code to allow for more flexibility when looking up Exact names, which
      can be assigned the wrong namespace during fixity declaration
      conversion.
      
      See the ticket for more info.
      d782694f
  14. 21 Jul, 2014 1 commit
    • Edward Z. Yang's avatar
      Rename PackageId to PackageKey, distinguishing it from Cabal's PackageId. · 4bebab25
      Edward Z. Yang authored
      Summary:
      Previously, both Cabal and GHC defined the type PackageId, and we expected
      them to be roughly equivalent (but represented differently).  This refactoring
      separates these two notions.
      
      A package ID is a user-visible identifier; it's the thing you write in a
      Cabal file, e.g. containers-0.9.  The components of this ID are semantically
      meaningful, and decompose into a package name and a package vrsion.
      
      A package key is an opaque identifier used by GHC to generate linking symbols.
      Presently, it just consists of a package name and a package version, but
      pursuant to #9265 we are planning to extend it to record other information.
      Within a single executable, it uniquely identifies a package.  It is *not* an
      InstalledPackageId, as the choice of a package key affects the ABI of a package
      (whereas an InstalledPackageId is computed after compilation.)  Cabal computes
      a package key for the package and passes it to GHC using -package-name (now
      *extremely* misnamed).
      
      As an added bonus, we don't have to worry about shadowing anymore.
      
      As a follow on, we should introduce -current-package-key having the same role as
      -package-name, and deprecate the old flag.  This commit is just renaming.
      
      The haddock submodule needed to be updated.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, simonmar, hvr, austin
      
      Subscribers: simonmar, relrod, carter
      
      Differential Revision: https://phabricator.haskell.org/D79
      
      Conflicts:
      	compiler/main/HscTypes.lhs
      	compiler/main/Packages.lhs
      	utils/haddock
      4bebab25
  15. 12 Jun, 2014 1 commit
    • Simon Peyton Jones's avatar
      Fix elemLocalRdrEnv (Trac #9160) · b637585d
      Simon Peyton Jones authored
      This was pretty obscure.  elemLocalRdrEnv was utterly wrong (replied
      False when it should reply True) when given an Exact Name. That
      doesn't happen often, but it does happen in the result of a TH splice.
      The result was that an associated type didn't get a type variable that
      lined up with its parent class (elemLocalRdrEnv is used in
      RnTypes.bindHsTyVars), and that messed up the singletons package.
      
      I've made a completely different test case to show up the bug:
      indexed_types/should_fail/T9160
      
      I also refactored RdrName.LocalRdrEnv to be a record with named
      fields, which makes the code more robust and easy to understand.
      b637585d
  16. 15 May, 2014 1 commit
    • Herbert Valerio Riedel's avatar
      Add LANGUAGE pragmas to compiler/ source files · 23892440
      Herbert Valerio Riedel authored
      In some cases, the layout of the LANGUAGE/OPTIONS_GHC lines has been
      reorganized, while following the convention, to
      
      - place `{-# LANGUAGE #-}` pragmas at the top of the source file, before
        any `{-# OPTIONS_GHC #-}`-lines.
      
      - Moreover, if the list of language extensions fit into a single
        `{-# LANGUAGE ... -#}`-line (shorter than 80 characters), keep it on one
        line. Otherwise split into `{-# LANGUAGE ... -#}`-lines for each
        individual language extension. In both cases, try to keep the
        enumeration alphabetically ordered.
        (The latter layout is preferable as it's more diff-friendly)
      
      While at it, this also replaces obsolete `{-# OPTIONS ... #-}` pragma
      occurences by `{-# OPTIONS_GHC ... #-}` pragmas.
      23892440
  17. 13 Feb, 2014 1 commit
  18. 09 Jan, 2014 1 commit
    • Simon Peyton Jones's avatar
      Re-work the naming story for the GHCi prompt (Trac #8649) · 73c08ab1
      Simon Peyton Jones authored
      The basic idea here is simple, and described in Note [The interactive package]
      in HscTypes, which starts thus:
      
          Note [The interactive package]
          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
          Type and class declarations at the command prompt are treated as if
          they were defined in modules
             interactive:Ghci1
             interactive:Ghci2
             ...etc...
          with each bunch of declarations using a new module, all sharing a
          common package 'interactive' (see Module.interactivePackageId, and
          PrelNames.mkInteractiveModule).
      
          This scheme deals well with shadowing.  For example:
      
             ghci> data T = A
             ghci> data T = B
             ghci> :i A
             data Ghci1.T = A  -- Defined at <interactive>:2:10
      
          Here we must display info about constructor A, but its type T has been
          shadowed by the second declaration.  But it has a respectable
          qualified name (Ghci1.T), and its source location says where it was
          defined.
      
          So the main invariant continues to hold, that in any session an original
          name M.T only refers to oe unique thing.  (In a previous iteration both
          the T's above were called :Interactive.T, albeit with different uniques,
          which gave rise to all sorts of trouble.)
      
      This scheme deals nicely with the original problem.  It allows us to
      eliminate a couple of grotseque hacks
        - Note [Outputable Orig RdrName] in HscTypes
        - Note [interactive name cache] in IfaceEnv
      (both these comments have gone, because the hacks they describe are no
      longer necessary). I was also able to simplify Outputable.QueryQualifyName,
      so that it takes a Module/OccName as args rather than a Name.
      
      However, matters are never simple, and this change took me an
      unreasonably long time to get right.  There are some details in
      Note [The interactive package] in HscTypes.
      73c08ab1
  19. 03 Jan, 2014 1 commit
    • Simon Peyton Jones's avatar
      Refactor the way shadowing in handled in GHCi · 5dffb4ac
      Simon Peyton Jones authored
      If you say
        ghci> import Foo( T )
        ghci> data T = MkT
        ghci> data T = XXX
      then the second 'data T' should shadow the first.  But the qualified
      Foo.T should still be available.  We really weren't handling this
      correctly at all, resulting in Trac #8639 and #8628 among others
      
      This patch:
      
      * Add RdrName.extendGlobalRdrEnv, which does shadowing properly
      
      * Change HscTypes.icExtendGblRdrEnv (was badly-named icPlusGblRdrEnv)
        to use the new function
      
      * Change RnNames.extendGobalRdrEnvRn to use the new function
      
      * Move gresFrom Avails into RdrName
      * Better pprGlobalRdrEnv function in RdrName
      5dffb4ac
  20. 22 Nov, 2013 1 commit
    • Simon Peyton Jones's avatar
      A raft of changes driven by Trac #8540 · 78814882
      Simon Peyton Jones authored
      The root cause of #8450 is that the new Template Haskell story, with
      the renamer doing more of the work of Template Haskell, wasn't dealing
      correctly with the keepAlive problem.  Consider
          g = ..blah...
          f = [| g |]
      Then f's RHS refers to g's name but not to g, so g was being discarded
      as dead code.
      
      Fixing this sucked me into a deep swamp of understanding how all the moving
      parts of hte new Template Haskell fit together, leading to a large collection
      of related changes and better documentation.  Specifically:
      
      * Instead of putting the TH level of a binder in the LocalRdrEnv, there
        is now a separate field
            tcl_th_bndrs :: NameEnv (TopLevelFlag, ThLevel)
        in the TcLclEnv, which records for each binder
           a) whether it is syntactically a top-level binder or not
           b) its TH level
        This deals uniformly with top-level and non-top-level binders, which was
        previously dealt with via greviously-delicate meddling with Internal and
        External Names.  Much better.
      
      * As a result I could remove the tct_level field of ATcId.
      
      * There are consequential changes in TcEnv too, which must also extend the
        level bindings.  Again, more clarity.
      
        I renamed TcEnv.tcExtendTcTyThingEnv to tcExtendKindEnv2, since it's only used
        during kind inference, for (AThing kind) and APromotionErr; and that is
        relevant to whether we want to extend the tcl_th_bndrs field (no).
      
      * I de-crufted the code in RnEnv.extendGlobalRdrEnv, by getting rid of the
        qual_gre code which said "Seems like 5 times as much work as it deserves!".
        Instead, RdrName.pickGREs makes the Internal names shadow External ones.
      
      * I moved the checkThLocalName cross-stage test to finishHsVar; previously
        we weren't doing the test at all in the OpApp case!
      
      * Quite a few changes (shortening the code) in the cross-stage checking code
        in TcExpr and RnSplice, notably to move the keepAlive call to the renamer
      
      One leftover piece:
      
      * In TcEnv I removed tcExtendGhciEnv and refactored
        tcExtendGlobalTyVars; this is really related to the next commit, but
        it was too hard to disentangle.
      78814882
  21. 04 Oct, 2013 1 commit
  22. 28 Jul, 2013 1 commit
  23. 14 Feb, 2013 1 commit
  24. 21 Aug, 2012 1 commit
  25. 12 Jun, 2012 1 commit
  26. 30 Mar, 2012 1 commit
  27. 28 Mar, 2012 1 commit
  28. 24 Mar, 2012 1 commit
  29. 23 Dec, 2011 1 commit
  30. 19 Dec, 2011 1 commit
    • Simon Peyton Jones's avatar
      Tidy up pretty-printing for variables · c492e50b
      Simon Peyton Jones authored
      We already have a class OutputableBndr; this patch adds
      methods pprInfixOcc and pprPrefixOcc, so that we can get
      rid of the hideous hack (the old) Outputable.pprHsVar.
      
      The hack was exposed by Trac #5657, which is thereby fixed.
      c492e50b
  31. 11 Nov, 2011 1 commit
    • dreixel's avatar
      New kind-polymorphic core · 09015be8
      dreixel authored
      This big patch implements a kind-polymorphic core for GHC. The current
      implementation focuses on making sure that all kind-monomorphic programs still
      work in the new core; it is not yet guaranteed that kind-polymorphic programs
      (using the new -XPolyKinds flag) will work.
      
      For more information, see http://haskell.org/haskellwiki/GHC/Kinds
      09015be8
  32. 04 Nov, 2011 1 commit
  33. 21 Sep, 2011 1 commit
    • Simon Marlow's avatar
      Add support for all top-level declarations to GHCi · 3db75724
      Simon Marlow authored
        This is work mostly done by Daniel Winograd-Cort during his
        internship at MSR Cambridge, with some further refactoring by me.
      
      This commit adds support to GHCi for most top-level declarations that
      can be used in Haskell source files.  Class, data, newtype, type,
      instance are all supported, as are Type Family-related declarations.
      
      The current set of declarations are shown by :show bindings.  As with
      variable bindings, entities bound by newer declarations shadow earlier
      ones.
      
      Tests are in testsuite/tests/ghci/scripts/ghci039--ghci054.
      Documentation to follow.
      3db75724
  34. 02 Sep, 2011 1 commit
  35. 22 Aug, 2011 1 commit
    • Simon Peyton Jones's avatar
      A batch of changes related to the handling of binders in instance decls · f76f0d0e
      Simon Peyton Jones authored
      The issue is that in
          instnace C T where
            data S = ...
            f = ...
      neither S nor f is really a binder; they are *occurrences*.  Moreover
      Haskell dictates that these particular occurrences are disambiguated
      by looking at the class whose instance they occur in.
      
      Some of this was not handled right for associated types.  And
      RnNames.getLocalNonValBinders was a bit messhy; this patch tidies it
      up.
      
      (And thenM is finally gone from RnSource.)
      f76f0d0e
  36. 05 Aug, 2011 2 commits
  37. 02 Aug, 2011 2 commits
    • Simon Peyton Jones's avatar
      78976235
    • Simon Peyton Jones's avatar
      Refactor the imports of InteractiveContext · 35d213ab
      Simon Peyton Jones authored
      Instead of two fields
         ic_toplev_scope :: [Module]
         ic_imports      :: [ImportDecl RdrName]
      
      we now just have one
         ic_imports :: [InteractiveImport]
      with the auxiliary data type
         data InteractiveImport
          = IIDecl (ImportDecl RdrName)  -- Bring the exports of a particular module
          	   	       		   -- (filtered by an import decl) into scope
      
          | IIModule Module	-- Bring into scope the entire top-level envt of
          	     		-- of this module, including the things imported
      			-- into it.
      
      This makes lots of code less confusing.  No change in behaviour.
      It's preparatory to fixing Trac #5147.
      
      While I was at I also
        * Cleaned up the handling of the "implicit" Prelude import
          by adding a ideclImplicit field to ImportDecl.  This
          significantly reduces plumbing in the handling of
          the implicit Prelude import
      
        * Used record notation consistently for ImportDecl
      35d213ab