1. 22 Apr, 2016 1 commit
    • Simon Peyton Jones's avatar
      Avoid double error on out-of-scope identifier · c2b7a3d9
      Simon Peyton Jones authored
      Trac #11941 demonstrated a case where an out-of-scope error also
      gave rise to a (bogus and confusing) stage restriction message.
      
      It's caused by the fact that out-of-scope errors do not stop
      renaming, but rather return an "unbound name".  We need to
      detect this in the stage-restriction test to avoid the double
      error.  Easy fix.
      c2b7a3d9
  2. 17 Apr, 2016 1 commit
  3. 12 Apr, 2016 1 commit
    • eir@cis.upenn.edu's avatar
      Fix #11797. · dd99f2ec
      eir@cis.upenn.edu authored
      DsMeta curiously omitted quantified tyvars in certain circumstances.
      This patch means it doesn't.
      
      Test case: th/T11797
      dd99f2ec
  4. 11 Apr, 2016 1 commit
    • Ryan Scott's avatar
      Filter out invisible kind arguments during TH reification · 02a5c580
      Ryan Scott authored
      Previously, all kind arguments were being reified, which would cause
      something like this:
      
      ```
      type Id a = a
      data Proxy (a :: Id k) = Proxy
      ```
      
      to output
      
      ```
      data Proxy (a :: Id * k) = Proxy
      ```
      
      when `Proxy`'s `Info` is reified. The fix is simple: simply call
      `filterOutInvisibleTypes` on the kind arguments of a kind synonym
      application.
      
      Fixes #11463.
      
      Test Plan: ./validate
      
      Reviewers: austin, bgamari, goldfire
      
      Reviewed By: goldfire
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2081
      
      GHC Trac Issues: #11463
      02a5c580
  5. 10 Apr, 2016 2 commits
    • Jason Eisenberg's avatar
      Fix suggestions for unbound variables (#11680) · 470d4d5b
      Jason Eisenberg authored
      When the typechecker generates the error message for an out-of-scope
      variable, it now uses the GlobalRdrEnv with respect to which the
      variable is unbound, not the GlobalRdrEnv which is available at the time
      the error is reported.  Doing so ensures we do not provide suggestions
      which themselves are out-of-scope (because they are bound in a later
      inter-splice group).
      
      Nonetheless, we do note in the error message if an unambiguous, exact
      match to the out-of-scope variable is found in a later inter-splice
      group, and we specify where that match is not in scope.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, austin, bgamari
      
      Reviewed By: goldfire
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2000
      
      GHC Trac Issues: #11680
      470d4d5b
    • bollmann's avatar
      Fix Template Haskell bug reported in #11809. · 2f82da76
      bollmann authored
      Record selectors of data types spliced in with Template Haskell are not
      renamer-resolved correctly in GHC HEAD. The culprit is
      `newRecordSelector` which violates notes `Note [Binders in Template
      Haskell] in Convert.hs` and `Note [Looking up Exact RdrNames] in
      RnEnv.hs`. This commit fixes `newRecordSelector` accordingly.
      
      Test Plan: ./validate
      
      Reviewers: thomie, mpickering, bgamari, austin, simonpj, goldfire
      
      Reviewed By: goldfire
      
      Differential Revision: https://phabricator.haskell.org/D2091
      
      GHC Trac Issues: #11809
      2f82da76
  6. 24 Mar, 2016 1 commit
  7. 11 Mar, 2016 1 commit
    • bollmann's avatar
      add regression test for #11145. · f3def764
      bollmann authored
      The original TH failure observed by the ticket, namely that Template
      Haskell quotes of data instance GADTs are broken, is not observable
      anymore in HEAD. I therefore just added the corresponding regression
      test.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, austin, thomie, jstolarek, bgamari
      
      Reviewed By: bgamari
      
      Differential Revision: https://phabricator.haskell.org/D1978
      
      GHC Trac Issues: #11145
      f3def764
  8. 25 Feb, 2016 1 commit
  9. 17 Feb, 2016 1 commit
  10. 10 Feb, 2016 1 commit
  11. 27 Jan, 2016 2 commits
    • eir@cis.upenn.edu's avatar
      Refactor the typechecker to use ExpTypes. · 00cbbab3
      eir@cis.upenn.edu authored
      The idea here is described in [wiki:Typechecker]. Briefly,
      this refactor keeps solid track of "synthesis" mode vs
      "checking" in GHC's bidirectional type-checking algorithm.
      When in synthesis mode, the expected type is just an IORef
      to write to.
      
      In addition, this patch does a significant reworking of
      RebindableSyntax, allowing much more freedom in the types
      of the rebindable operators. For example, we can now have
      `negate :: Int -> Bool` and
      `(>>=) :: m a -> (forall x. a x -> m b) -> m b`. The magic
      is in tcSyntaxOp.
      
      This addresses tickets #11397, #11452, and #11458.
      
      Tests:
        typecheck/should_compile/{RebindHR,RebindNegate,T11397,T11458}
        th/T11452
      00cbbab3
    • thomie's avatar
      Testsuite: fixup req_profiling tests (#11496) · eeb67c9b
      thomie authored
      * T2552 (#10037) is failng for all threaded opt_ways, not for WAY=prof.
      * TH_spliceE5_prof (#11495) is failing when ghc_dynamic
      * Rename ghci_dynamic to ghc_dynamic. It's the same thing.
      eeb67c9b
  12. 09 Jan, 2016 2 commits
  13. 08 Jan, 2016 1 commit
    • Ryan Scott's avatar
      Fix Template Haskell's handling of infix GADT constructors · 01634277
      Ryan Scott authored
      This is the second (and hopefully last) fix needed to make TH handle
      GADTs properly (after D1465). This Diff addresses some issues with infix
      GADT constructors, specifically:
      
      * Before, you could not determine if a GADT constructor was declared
        infix because TH did not give you the ability to determine if there is
        a //user-specified// fixity declaration for that constructor. The
        return type of `reifyFixity` was changed to `Maybe Fixity` so that it
        yields `Just` the fixity is there is a fixity declaration, and
        `Nothing` otherwise (indicating it has `defaultFixity`).
      * `DsMeta`/`Convert` were changed so that infix GADT constructors are
        turned into `GadtC`, not `InfixC` (which should be reserved for
        Haskell98 datatype declarations).
      * Some minor fixes to the TH pretty-printer so that infix GADT
        constructors will be parenthesized in GADT signatures.
      
      Fixes #11345.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, austin, bgamari, jstolarek
      
      Reviewed By: jstolarek
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1744
      
      GHC Trac Issues: #11345
      01634277
  14. 06 Jan, 2016 1 commit
  15. 03 Jan, 2016 1 commit
  16. 28 Dec, 2015 1 commit
    • Herbert Valerio Riedel's avatar
      Synchronise ghci-package version with ghc-package · 01299ca8
      Herbert Valerio Riedel authored
      In order to simplify the task, the version munging logic has
      been radically simplified:
      
      Previously, in cases where the version contained dates as version components,
      the build-system would munge the version of the stage1 ghc package before
      registering the `ghc` package.
      
      However, this hack was already questionable at the time of its introduction
      (c.f. 7b45c46c).
      Simplifying the build-systems by avoiding such hacks may also help the
      shaking-up-ghc effort.
      
      So now we simply munge directly via the `.cabal` files, which gives a simpler
      picture, as now every stage is munged the same. Munging is only active when
      the first patch-level version component is a date. So stable snapshots and release
      candidates are unaffacted (as those have the date in the second patch-level
      version component)
      
      Reviewers: simonmar, bgamari, austin, thomie, ezyang
      
      Reviewed By: bgamari, thomie, ezyang
      
      Differential Revision: https://phabricator.haskell.org/D1673
      01299ca8
  17. 26 Dec, 2015 1 commit
    • eir@cis.upenn.edu's avatar
      Fix #11287. · da69358b
      eir@cis.upenn.edu authored
      Happily, the fix is simply deleting some old code. I love it when
      that happens.
      da69358b
  18. 25 Dec, 2015 1 commit
  19. 24 Dec, 2015 1 commit
    • thomie's avatar
      Don't drop last char of file if -osuf contains dot · 48db13d2
      thomie authored
      Given:
       * `file = "foo.a.b"`
       * `osuf = ".a.b"`  -- Note the initial dot.
       * `new_osuf = "c"`
      
      Before (bad, the last character of the filename is dropped):
        `dropTail (length osuf + 1) file <.> new_osuf == "fo.c"`
      After (good):
        `stripExtension osuf file <.> new_osuf` == "foo.c"
      
      This regression was introduced in commit c489af73 (#5554). That commit
      fixed a similar but different bug, and care has been taken to not
      reintroduce it (using the the newly introduced
      `System.Filepath.stripExtension`).
      
      Given:
       * `file = "foo.a.b"`
       * `osuf = "a.b"`
       * `new_osuf = "c"`
      
      Before c489af73 (bad, the full suffix should get replaced):
        `replaceExtension file new_osuf == "foo.a.c"`
      After c489af73 (good):
        `dropTail (length osuf + 1) file <.> new_osuf == "foo.c"`
      After this commit (still good):
        `stripExtension osuf file <.> new_osuf == "foo.c"`
      
      Reviewed by: bgamari
      
      Differential Revision: https://phabricator.haskell.org/D1692
      
      GHC Trac Issues: #9760
      48db13d2
  20. 22 Dec, 2015 1 commit
    • Ryan Scott's avatar
      Rework Template Haskell's handling of strictness · f975b0b1
      Ryan Scott authored
      Currently, Template Haskell's treatment of strictness is not enough to
      cover all possible combinations of unpackedness and strictness. In
      addition, it isn't equipped to deal with new features (such as
      `-XStrictData`) which can change a datatype's fields' strictness during
      compilation.
      
      To address this, I replaced TH's `Strict` datatype with
      `SourceUnpackedness` and `SourceStrictness` (which give the programmer a
      more complete toolkit to configure a datatype field's strictness than
      just `IsStrict`, `IsLazy`, and `Unpack`). I also added the ability to
      reify a constructor fields' strictness post-compilation through the
      `reifyConStrictness` function.
      
      Fixes #10697.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, goldfire, bgamari, austin
      
      Reviewed By: goldfire, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1603
      
      GHC Trac Issues: #10697
      f975b0b1
  21. 21 Dec, 2015 1 commit
  22. 17 Dec, 2015 1 commit
    • Simon Marlow's avatar
      Remote GHCi, -fexternal-interpreter · 4905b83a
      Simon Marlow authored
      Summary:
      (Apologies for the size of this patch, I couldn't make a smaller one
      that was validate-clean and also made sense independently)
      
      (Some of this code is derived from GHCJS.)
      
      This commit adds support for running interpreted code (for GHCi and
      TemplateHaskell) in a separate process.  The functionality is
      experimental, so for now it is off by default and enabled by the flag
      -fexternal-interpreter.
      
      Reaosns we want this:
      
      * compiling Template Haskell code with -prof does not require
        building the code without -prof first
      
      * when GHC itself is profiled, it can interpret unprofiled code, and
        the same applies to dynamic linking.  We would no longer need to
        force -dynamic-too with TemplateHaskell, and we can load ordinary
        objects into a dynamically-linked GHCi (and vice versa).
      
      * An unprofiled GHCi can load and run profiled code, which means it
        can use the stack-trace functionality provided by profiling without
        taking the performance hit on the compiler that profiling would
        entail.
      
      Amongst other things; see
      https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi for more details.
      
      Notes on the implementation are in Note [Remote GHCi] in the new
      module compiler/ghci/GHCi.hs.  It probably needs more documenting,
      feel free to suggest things I could elaborate on.
      
      Things that are not currently implemented for -fexternal-interpreter:
      
      * The GHCi debugger
      * :set prog, :set args in GHCi
      * `recover` in Template Haskell
      * Redirecting stdin/stdout for the external process
      
      These are all doable, I just wanted to get to a working validate-clean
      patch first.
      
      I also haven't done any benchmarking yet.  I expect there to be slight hit
      to link times for byte code and some penalty due to having to
      serialize/deserialize TH syntax, but I don't expect it to be a serious
      problem.  There's also lots of low-hanging fruit in the byte code
      generator/linker that we could exploit to speed things up.
      
      Test Plan:
      * validate
      * I've run parts of the test suite with
      EXTRA_HC_OPTS=-fexternal-interpreter, notably tests/ghci and tests/th.
      There are a few failures due to the things not currently implemented
      (see above).
      
      Reviewers: simonpj, goldfire, ezyang, austin, alanz, hvr, niteria, bgamari, gibiansky, luite
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1562
      4905b83a
  23. 15 Dec, 2015 1 commit
    • Ben Gamari's avatar
      Expose enabled language extensions to TH · c1e25536
      Ben Gamari authored
      This exposes `template-haskell` functions for querying the language
      extensions which are enabled when compiling a module,
      
      - an `isExtEnabled` function to check whether an extension is enabled
      - an `extsEnabled` function to obtain a full list of enabled extensions
      
      To avoid code duplication this adds a `GHC.LanguageExtensions` module to
      `ghc-boot` and moves `DynFlags.ExtensionFlag` into it. A happy
      consequence of this is that the ungainly `DynFlags` lost around 500
      lines. Moreover, flags corresponding to language extensions are now
      clearly distinguished from other flags due to the `LangExt.*` prefix.
      
      Updates haddock submodule.
      
      This fixes #10820.
      
      Test Plan: validate
      
      Reviewers: austin, spinda, hvr, goldfire, alanz
      
      Reviewed By: goldfire
      
      Subscribers: mpickering, RyanGlScott, hvr, simonpj, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1200
      
      GHC Trac Issues: #10820
      c1e25536
  24. 14 Dec, 2015 1 commit
    • Ben Gamari's avatar
      Use Cxt for deriving clauses in TH (#10819) · 04ab55d9
      Ben Gamari authored
      Summary:
      Deriving clauses in the TH representations of data, newtype, data
      instance, and newtype instance declarations previously were just [Name],
      which didn't allow for more complex derived classes, eg. multi-parameter
      typeclasses.
      
      This switches out [Name] for Cxt, representing the derived classes as
      types instead of names.
      
      Test Plan: validate
      
      Reviewers: goldfire, spinda, austin
      
      Reviewed By: goldfire, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1202
      
      GHC Trac Issues: #10819
      04ab55d9
  25. 07 Nov, 2015 2 commits
    • johnleo's avatar
      fix #10734 by adding braces to pretty-printing of let inside do · be885857
      johnleo authored
      Test Plan: validate
      
      Reviewers: bgamari, austin, goldfire
      
      Reviewed By: goldfire
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1448
      
      GHC Trac Issues: #10734
      be885857
    • Simon Marlow's avatar
      Make GHCi & TH work when the compiler is built with -prof · ce1f1607
      Simon Marlow authored
      Summary:
      Amazingly, there were zero changes to the byte code generator and very
      few changes to the interpreter - mainly because we've used good
      abstractions that hide the differences between profiling and
      non-profiling.  So that bit was pleasantly straightforward, but there
      were a pile of other wibbles to get the whole test suite through.
      
      Note that a compiler built with -prof is now like one built with
      -dynamic, in that to use TH you have to build the code the same way.
      For dynamic, we automatically enable -dynamic-too when TH is required,
      but we don't have anything equivalent for profiling, so you have to
      explicitly use -prof when building code that uses TH with a profiled
      compiler.  For this reason Cabal won't work with TH.  We don't expect
      to ship a profiled compiler, so I think that's OK.
      
      Test Plan: validate with GhcProfiled=YES in validate.mk
      
      Reviewers: goldfire, bgamari, rwbarton, austin, hvr, erikd, ezyang
      
      Reviewed By: ezyang
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1407
      
      GHC Trac Issues: #4837, #545
      ce1f1607
  26. 20 Oct, 2015 1 commit
    • Jan Stolarek's avatar
      Reject top-level typed TH splices. Fixes #10945 · 1750ebc2
      Jan Stolarek authored
      When TemplateHaskell language extension is enabled it is valid to have
      top-level expressions.  Each such expression is treated as a contents
      of a splice.  The problem arises with typed splices.  They are not valid
      at the top level and therefore we should interpret them not as a splice
      but as a top-level expression (aka. implicit splice).  So saying:
      
      $$foo
      
      is equivalent of:
      
      $( $$foo )
      
      This patch makes sure that this is indeed the case.  Until now we
      incorrectly treated typed splices as explicit splices.
      1750ebc2
  27. 16 Oct, 2015 1 commit
  28. 13 Oct, 2015 1 commit
    • Ryan Scott's avatar
      Make dataToQa aware of Data instances which use functions to implement toConstr · d2f9972a
      Ryan Scott authored
      Trac #10796 exposes a way to make `template-haskell`'s `dataToQa` function
      freak out if using a `Data` instance that produces a `Constr` (by means of
      `toConstr`) using a function name instead of a data constructor name. While
      such `Data` instances are somewhat questionable, they are nevertheless present
      in popular libraries (e.g., `containers`), so we can at least make `dataToQa`
      aware of their existence.
      
      In order to properly distinguish strings which represent variables (as opposed
      to data constructors), it was necessary to move functionality from `Lexeme` (in
      `ghc`) to `GHC.Lexeme` in a new `ghc-boot` library (which was previously named
      `bin-package-db`).
      
      Reviewed By: goldfire, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1313
      
      GHC Trac Issues: #10796
      d2f9972a
  29. 08 Oct, 2015 1 commit
  30. 26 Sep, 2015 1 commit
    • Ömer Sinan Ağacan's avatar
      reify associated types when reifying typeclasses(#10891) · b4d43b4e
      Ömer Sinan Ağacan authored
      As reported in Trac #10891, Template Haskell's `reify` was not
      generating Decls for associated types. This patch fixes that.
      
      Note that even though `reifyTyCon` function used in this patch returns
      some type instances, I'm ignoring that.
      
      Here's an example of how associated types are encoded with this patch:
      
      (Simplified representation)
      
          class C a where
            type F a :: *
      
          -->
      
          OpenTypeFamilyD "F" ["a"]
      
      With default type instances:
      
          class C a where
            type F a :: *
            type F a = a
      
          -->
      
          OpenTypeFamilyD "F" ["a"]
          TySynInstD "F" (TySynEqn [VarT "a"] "a")
      
      Test Plan:
      This patch was already reviewed and even merged. The patch is later
      reverted because apparently it broke the build some time between the
      validation of this patch and merge. Creating this new ticket to fix the
      validation.
      
      Reviewers: goldfire, austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1277
      
      GHC Trac Issues: #10891
      b4d43b4e
  31. 23 Sep, 2015 3 commits
  32. 22 Sep, 2015 1 commit
  33. 21 Sep, 2015 2 commits