1. 16 Nov, 2015 2 commits
  2. 13 Nov, 2015 3 commits
  3. 11 Nov, 2015 1 commit
  4. 30 Oct, 2015 1 commit
    • Ben Gamari's avatar
      Generate Typeable info at definition sites · 91c6b1f5
      Ben Gamari authored
      This is the second attempt at merging D757.
      
      This patch implements the idea floated in Trac #9858, namely that we
      should generate type-representation information at the data type
      declaration site, rather than when solving a Typeable constraint.
      
      However, this turned out quite a bit harder than I expected. I still
      think it's the right thing to do, and it's done now, but it was quite
      a struggle.
      
      See particularly
      
       * Note [Grand plan for Typeable] in TcTypeable (which is a new module)
       * Note [The overall promotion story] in DataCon (clarifies existing
      stuff)
      
      The most painful bit was that to generate Typeable instances (ie
      TyConRepName bindings) for every TyCon is tricky for types in ghc-prim
      etc:
      
       * We need to have enough data types around to *define* a TyCon
       * Many of these types are wired-in
      
      Also, to minimise the code generated for each data type, I wanted to
      generate pure data, not CAFs with unpackCString# stuff floating about.
      
      Performance
      ~~~~~~~~~~~
      Three perf/compiler tests start to allocate quite a bit more. This isn't
      surprising, because they all allocate zillions of data types, with
      practically no other code, esp. T1969
      
       * T1969:    GHC allocates 19% more
       * T4801:    GHC allocates 13% more
       * T5321FD:  GHC allocates 13% more
       * T9675:    GHC allocates 11% more
       * T783:     GHC allocates 11% more
       * T5642:    GHC allocates 10% more
      
      I'm treating this as acceptable. The payoff comes in Typeable-heavy
      code.
      
      Remaining to do
      ~~~~~~~~~~~~~~~
      
       * I think that "TyCon" and "Module" are over-generic names to use for
         the runtime type representations used in GHC.Typeable. Better might
      be
         "TrTyCon" and "TrModule". But I have not yet done this
      
       * Add more info the the "TyCon" e.g. source location where it was
         defined
      
       * Use the new "Module" type to help with Trac Trac #10068
      
       * It would be possible to generate TyConRepName (ie Typeable
         instances) selectively rather than all the time. We'd need to persist
         the information in interface files. Lacking a motivating reason I
      have
         not done this, but it would not be difficult.
      
      Refactoring
      ~~~~~~~~~~~
      As is so often the case, I ended up refactoring more than I intended.
      In particular
      
       * In TyCon, a type *family* (whether type or data) is repesented by a
         FamilyTyCon
           * a algebraic data type (including data/newtype instances) is
             represented by AlgTyCon This wasn't true before; a data family
             was represented as an AlgTyCon. There are some corresponding
             changes in IfaceSyn.
      
           * Also get rid of the (unhelpfully named) tyConParent.
      
       * In TyCon define 'Promoted', isomorphic to Maybe, used when things are
         optionally promoted; and use it elsewhere in GHC.
      
       * Cleanup handling of knownKeyNames
      
       * Each TyCon, including promoted TyCons, contains its TyConRepName, if
         it has one. This is, in effect, the name of its Typeable instance.
      
      Updates haddock submodule
      
      Test Plan: Let Harbormaster validate
      
      Reviewers: austin, hvr, goldfire
      
      Subscribers: goldfire, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1404
      
      GHC Trac Issues: #9858
      91c6b1f5
  5. 29 Oct, 2015 3 commits
    • Ben Gamari's avatar
      Revert "Generate Typeable info at definition sites" · bbaf76f9
      Ben Gamari authored
      This reverts commit bef2f03e.
      
      This merge was botched
      
      Also reverts haddock submodule.
      bbaf76f9
    • Ben Gamari's avatar
      Generate Typeable info at definition sites · bef2f03e
      Ben Gamari authored
      This patch implements the idea floated in Trac #9858, namely that we
      should generate type-representation information at the data type
      declaration site, rather than when solving a Typeable constraint.
      
      However, this turned out quite a bit harder than I expected. I still
      think it's the right thing to do, and it's done now, but it was quite
      a struggle.
      
      See particularly
      
       * Note [Grand plan for Typeable] in TcTypeable (which is a new module)
       * Note [The overall promotion story] in DataCon (clarifies existing stuff)
      
      The most painful bit was that to generate Typeable instances (ie
      TyConRepName bindings) for every TyCon is tricky for types in ghc-prim
      etc:
      
       * We need to have enough data types around to *define* a TyCon
       * Many of these types are wired-in
      
      Also, to minimise the code generated for each data type, I wanted to
      generate pure data, not CAFs with unpackCString# stuff floating about.
      
      Performance
      ~~~~~~~~~~~
      Three perf/compiler tests start to allocate quite a bit more. This isn't
      surprising, because they all allocate zillions of data types, with
      practically no other code, esp. T1969
      
       * T3294:   GHC allocates 110% more (filed #11030 to track this)
       * T1969:   GHC allocates 30% more
       * T4801:   GHC allocates 14% more
       * T5321FD: GHC allocates 13% more
       * T783:    GHC allocates 12% more
       * T9675:   GHC allocates 12% more
       * T5642:   GHC allocates 10% more
       * T9961:   GHC allocates 6% more
      
       * T9203:   Program allocates 54% less
      
      I'm treating this as acceptable. The payoff comes in Typeable-heavy
      code.
      
      Remaining to do
      ~~~~~~~~~~~~~~~
      
       * I think that "TyCon" and "Module" are over-generic names to use for
         the runtime type representations used in GHC.Typeable. Better might be
         "TrTyCon" and "TrModule". But I have not yet done this
      
       * Add more info the the "TyCon" e.g. source location where it was
         defined
      
       * Use the new "Module" type to help with Trac Trac #10068
      
       * It would be possible to generate TyConRepName (ie Typeable
         instances) selectively rather than all the time. We'd need to persist
         the information in interface files. Lacking a motivating reason I have
         not done this, but it would not be difficult.
      
      Refactoring
      ~~~~~~~~~~~
      As is so often the case, I ended up refactoring more than I intended.
      In particular
      
       * In TyCon, a type *family* (whether type or data) is repesented by a
         FamilyTyCon
           * a algebraic data type (including data/newtype instances) is
             represented by AlgTyCon This wasn't true before; a data family
             was represented as an AlgTyCon. There are some corresponding
             changes in IfaceSyn.
      
           * Also get rid of the (unhelpfully named) tyConParent.
      
       * In TyCon define 'Promoted', isomorphic to Maybe, used when things are
         optionally promoted; and use it elsewhere in GHC.
      
       * Cleanup handling of knownKeyNames
      
       * Each TyCon, including promoted TyCons, contains its TyConRepName, if
         it has one. This is, in effect, the name of its Typeable instance.
      
      Requires update of the haddock submodule.
      
      Differential Revision: https://phabricator.haskell.org/D757
      bef2f03e
    • Matthew Pickering's avatar
      Record pattern synonyms · 2a74a64e
      Matthew Pickering authored
      This patch implements an extension to pattern synonyms which allows user
      to specify pattern synonyms using record syntax. Doing so generates
      appropriate selectors and update functions.
      
      === Interaction with Duplicate Record Fields ===
      
      The implementation given here isn't quite as general as it could be with
      respect to the recently-introduced `DuplicateRecordFields` extension.
      
      Consider the following module:
      
          {-# LANGUAGE DuplicateRecordFields #-}
          {-# LANGUAGE PatternSynonyms #-}
      
          module Main where
      
          pattern S{a, b} = (a, b)
          pattern T{a}    = Just a
      
          main = do
            print S{ a = "fst", b = "snd" }
            print T{ a = "a" }
      
      In principle, this ought to work, because there is no ambiguity. But at
      the moment it leads to a "multiple declarations of a" error. The problem
      is that pattern synonym record selectors don't do the same name mangling
      as normal datatypes when DuplicateRecordFields is enabled. They could,
      but this would require some work to track the field label and selector
      name separately.
      
      In particular, we currently represent datatype selectors in the third
      component of AvailTC, but pattern synonym selectors are just represented
      as Avails (because they don't have a corresponding type constructor).
      Moreover, the GlobalRdrElt for a selector currently requires it to have
      a parent tycon.
      
      (example due to Adam Gundry)
      
      === Updating Explicitly Bidirectional Pattern Synonyms ===
      
      Consider the following
      
      ```
      pattern Silly{a} <- [a] where
        Silly a = [a, a]
      
      f1 = a [5] -- 5
      
      f2 = [5] {a = 6} -- currently [6,6]
      ```
      
      === Fixing Polymorphic Updates ===
      
      They were fixed by adding these two lines in `dsExpr`. This might break
      record updates but will be easy to fix.
      
      ```
      + ; let req_wrap = mkWpTyApps (mkTyVarTys univ_tvs)
      
      - , pat_wrap = idHsWrapper }
      +, pat_wrap = req_wrap }
      ```
      
      === Mixed selectors error ===
      
      Note [Mixed Record Field Updates]
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      Consider the following pattern synonym.
      
          data MyRec = MyRec { foo :: Int, qux :: String }
      
          pattern HisRec{f1, f2} = MyRec{foo = f1, qux=f2}
      
      This allows updates such as the following
      
          updater :: MyRec -> MyRec
          updater a = a {f1 = 1 }
      
      It would also make sense to allow the following update (which we
      reject).
      
          updater a = a {f1 = 1, qux = "two" } ==? MyRec 1 "two"
      
      This leads to confusing behaviour when the selectors in fact refer the
      same field.
      
          updater a = a {f1 = 1, foo = 2} ==? ???
      
      For this reason, we reject a mixture of pattern synonym and normal
      record selectors in the same update block. Although of course we still
      allow the following.
      
          updater a = (a {f1 = 1}) {foo = 2}
      
          > updater (MyRec 0 "str")
          MyRec 2 "str"
      2a74a64e
  6. 17 Oct, 2015 1 commit
    • Herbert Valerio Riedel's avatar
      Make Monad/Applicative instances MRP-friendly · e8ed2136
      Herbert Valerio Riedel authored
      This patch refactors pure/(*>) and return/(>>) in MRP-friendly way, i.e.
      such that the explicit definitions for `return` and `(>>)` match the
      MRP-style default-implementation, i.e.
      
        return = pure
      
      and
      
        (>>) = (*>)
      
      This way, e.g. all `return = pure` definitions can easily be grepped and
      removed in GHC 8.1;
      
      Test Plan: Harbormaster
      
      Reviewers: goldfire, alanz, bgamari, quchen, austin
      
      Reviewed By: quchen, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1312
      e8ed2136
  7. 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
  8. 15 Oct, 2015 2 commits
    • Edward Z. Yang's avatar
      Rename package key to unit ID, and installed package ID to component ID. · b92a51f5
      Edward Z. Yang authored
      Comes with Haddock submodule update.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      b92a51f5
    • Edward Z. Yang's avatar
      Update Cabal to HEAD, IPID renamed to Component ID. · 5b0191f7
      Edward Z. Yang authored
      This commit contains a Cabal submodule update which unifies installed
      package IDs and package keys under a single notion, a Component ID.
      We update GHC to keep follow this unification.  However, this commit
      does NOT rename installed package ID to component ID and package key to
      unit ID; the plan is to do that in a companion commit.
      
          - Compiler info now has "Requires unified installed package IDs"
      
          - 'exposed' is now expected to contain unit keys, not IPIDs.
      
          - Shadowing is no more.  We now just have a very simple strategy
            to deal with duplicate unit keys in combined package databases:
            if their ABIs are the same, use the latest one; otherwise error.
            Package databases maintain the invariant that there can only
            be one entry of a unit ID.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, austin, bgamari, hvr, goldfire
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1184
      
      GHC Trac Issues: #10714
      5b0191f7
  9. 09 Oct, 2015 1 commit
  10. 21 Sep, 2015 3 commits
    • Edward Z. Yang's avatar
      Fix build failure, I think. · d516d2e1
      Edward Z. Yang authored
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      d516d2e1
    • Edward Z. Yang's avatar
      Unify hsig and hs-boot; add preliminary "hs-boot" merging. · 06d46b1e
      Edward Z. Yang authored
      This patch drops the file level distinction between hs-boot and hsig;
      we figure out which one we are compiling based on whether or not there
      is a corresponding hs file lying around.
      
      To make the "import A" syntax continue to work for bare hs-boot
      files, we also introduce hs-boot merging, which takes an A.hi-boot
      and converts it to an A.hi when there is no A.hs file in scope.
      This will be generalized in Backpack to merge multiple A.hi files together;
      which means we can jettison the "load multiple interface files" functionality.
      
      This works automatically for --make, but for one-shot compilation
      we need a new mode: ghc --merge-requirements A will generate an A.hi/A.o
      from a local A.hi-boot file; Backpack will extend this mechanism further.
      
      Has Haddock submodule update to deal with change in msHsFilePath behavior.
      
          - This commit drops support for the hsig extension. Can
            we support it?  It's annoying because the finder code is
            written with the assumption that where there's an hs-boot
            file, there's always an hs file too.  To support hsig, you'd
            have to probe two locations.  Easier to just not support it.
      
          - #10333 affects us, modifying an hs-boot still doesn't trigger
            recomp.
      
          - See compiler/main/Finder.hs: this diff is very skeevy, but
            it seems to work.
      
          - This code cunningly doesn't drop hs-boot files from the
            "drop hs-boot files" module graph, if they don't have a
            corresponding hs file.  I have no idea if this actually is useful.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, austin, bgamari, spinda
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1098
      06d46b1e
    • Edward Z. Yang's avatar
      3f13c20e
  11. 27 Aug, 2015 1 commit
  12. 05 Aug, 2015 1 commit
    • Simon Peyton Jones's avatar
      Allow proper errors/warnings in core2core passes · e2b57381
      Simon Peyton Jones authored
      This patch makes it possible for core-to-core passes to emit
      proper error messages and warnings.
      
        * New function CoreMonad.warnMsg
      
        * CoreMonad.warnMsg and errorMsg now print a proper warning/error
          message heading.
      
        * CoreMonad carries a SrcSpan, which is used in warning/error
          messages.  It is initialised to be the source file name, but
          a core-to-core pass could set it more specifically if it had
          better location information.
      
      There was a bit of plumbing needed to get the filename to the
      right place.
      e2b57381
  13. 23 Jul, 2015 2 commits
  14. 22 Jul, 2015 1 commit
  15. 21 Jul, 2015 2 commits
  16. 09 Jul, 2015 1 commit
  17. 15 Jun, 2015 1 commit
  18. 11 Jun, 2015 1 commit
  19. 03 Jun, 2015 1 commit
    • Simon Peyton Jones's avatar
      Refactor RdrName.Provenance, to fix #7672 · 7ea156ae
      Simon Peyton Jones authored
      Trac #7672 has a data type T in module A that is in scope
      *both* locally-bound *and* imported (with a qualified) name.
      The Provenance of a GlobalRdrElt simply couldn't express that
      before. Now you can.
      
      In doing so, I flattened out Provenance into GlobalRdrElt,
      so quite a lot of modules are touched in a not-very-interesting
      way.
      7ea156ae
  20. 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
  21. 04 May, 2015 1 commit
    • Adam Gundry's avatar
      Permit empty closed type families · 4efa4213
      Adam Gundry authored
      Fixes #9840 and #10306, and includes an alternative resolution to #8028.
      This permits empty closed type families, and documents them in the user
      guide. It updates the Haddock submodule to support the API change.
      
      Test Plan: Added `indexed-types/should_compile/T9840` and updated
      `indexed-types/should_fail/ClosedFam4` and `th/T8028`.
      
      Reviewers: austin, simonpj, goldfire
      
      Reviewed By: goldfire
      
      Subscribers: bgamari, jstolarek, thomie, goldfire
      
      Differential Revision: https://phabricator.haskell.org/D841
      
      GHC Trac Issues: #9840, #10306
      4efa4213
  22. 07 Apr, 2015 2 commits
    • Edward Z. Yang's avatar
      Support for multiple signature files in scope. · a7524eae
      Edward Z. Yang authored
      Summary:
      A common pattern when programming with signatures is to combine multiple
      signatures together (signature linking).  We achieve this by making it
      not-an-error to have multiple, distinct interface files for the same module
      name, as long as they have the same backing implementation.  When a user
      imports a module name, they get ALL matching signatures dumped into their
      scope.
      
      On the way, I refactored the module finder code, which now distinguishes
      between exact finds (when you had a 'Module') and regular finds (when
      you had a 'ModuleName').  I also refactored the package finder code to
      use a Monoid instance on LookupResult to collect together various results.
      
      ToDo: At the moment, if a signature is declared in the local package,
      it completely overrides any remote signatures.  Eventually, we'll want
      to also pull in the remote signatures (or even override the local signature,
      if the full implementation is available.)  There are bunch of ToDos in the
      code for what to do once this is done.
      
      ToDo: At the moment, whenever a module name lookup occurs in GHCi and we
      would have seen a signature, we instead continue and return the Module
      for the backing implementation.  This is correct for most cases, but there
      might be some situations where we want something a little more fine-grained
      (e.g. :browse should only list identifiers which are available through
      the in-scope signatures, and not ALL of them.)
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, hvr, austin
      
      Subscribers: carter, thomie
      
      Differential Revision: https://phabricator.haskell.org/D790
      
      GHC Trac Issues: #9252
      a7524eae
    • Simon Peyton Jones's avatar
      Reduce module qualifiers in pretty-printing · 547c5971
      Simon Peyton Jones authored
      The change is in HscTypes.mkPrintUnqualified, and suppresses the
      module qualifier on Names from ghc-prim, base, and template-haskell,
      where no ambiguity can aries.  It's somewhat arbitrary, but helps
      with things like 'Constraint' which are often not in scope, but
      occasionally show up in error messages.
      547c5971
  23. 17 Mar, 2015 1 commit
    • Simon Peyton Jones's avatar
      Move declaration of Rulebase from Rules to CoreSyn · dbd92997
      Simon Peyton Jones authored
      This allow HscTypes to import CoreSyn rather than Rules, which makes
      module loops easier to avoid.  At one point in my recent travels this
      was important; I'm not sure it's so important now, but it's a good
      thing anyway.
      
      In any case CoreRule is defined in CoreSyn, so this move make sense.
      dbd92997
  24. 24 Feb, 2015 1 commit
  25. 17 Feb, 2015 1 commit
  26. 15 Feb, 2015 1 commit
  27. 10 Feb, 2015 1 commit
  28. 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
  29. 06 Jan, 2015 1 commit
    • Simon Peyton Jones's avatar
      Make the location in TcLclEnv and CtLoc into a RealSrcSpan · d2b6e767
      Simon Peyton Jones authored
      Previously it was a SrcSpan, which can be an UnhelpulSrcSpan,
      but actually for TcLclEnv and CtLoc we always know it is
      a real source location, and it's good to make the types
      reflect that fact.
      
      There is a continuing slight awkwardness (not new with this
      patch) about what "file name" to use for GHCi code.  Current
      we say "<interactive>" which seems just about OK.
      d2b6e767