1. 21 Jan, 2018 1 commit
    • Takenobu Tani's avatar
      Implement underscores in numeric literals (NumericUnderscores extension) · 4a13c5b1
      Takenobu Tani authored
      Implement the proposal of underscores in numeric literals.
      Underscores in numeric literals are simply ignored.
      
      The specification of the feature is available here:
      https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/000
      9-numeric-underscores.rst
      
      For a discussion of the various choices:
      https://github.com/ghc-proposals/ghc-proposals/pull/76
      
      Implementation detail:
      
      * Added dynamic flag
        * `NumericUnderscores` extension flag is added for this feature.
      
      * Alex "Regular expression macros" in Lexer.x
        * Add `@numspc` (numeric spacer) macro to represent multiple
          underscores.
        * Modify `@decimal`, `@decimal`, `@binary`, `@octal`, `@hexadecimal`,
          `@exponent`, and `@bin_exponent` macros to include `@numspc`.
      
      * Alex "Rules" in Lexer.x
        * To be simpler, we have only the definitions with underscores.
          And then we have a separate function (`tok_integral` and `tok_frac`)
          that validates the literals.
      
      * Validation functions in Lexer.x
        * `tok_integral` and `tok_frac` functions validate
          whether contain underscores or not.
          If `NumericUnderscores` extensions are not enabled,
          check that there are no underscores.
        * `tok_frac` function is created by merging `strtoken` and
          `init_strtoken`.
        * `init_strtoken` is deleted. Because it is no longer used.
      
      * Remove underscores from target literal string
        * `parseUnsignedInteger`, `readRational__`, and `readHexRational} use
          the customized `span'` function to remove underscores.
      
      * Added Testcase
        * testcase for NumericUnderscores enabled.
            NumericUnderscores0.hs and NumericUnderscores1.hs
        * testcase for NumericUnderscores disabled.
            NoNumericUnderscores0.hs and NoNumericUnderscores1.hs
        * testcase to invalid pattern for NumericUnderscores enabled.
            NumericUnderscoresFail0.hs and NumericUnderscoresFail1.hs
      
      Test Plan: `validate` including the above testcase
      
      Reviewers: goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: carter, rwbarton, thomie
      
      GHC Trac Issues: #14473
      
      Differential Revision: https://phabricator.haskell.org/D4235
      4a13c5b1
  2. 21 Dec, 2017 1 commit
    • Ryan Scott's avatar
      Fix #14588 by checking for more bang patterns · 9caf40e9
      Ryan Scott authored
      Summary:
      Commit 37299536
      inadvertently removed a check in the parser which rejected
      let-bindings with bang patterns, leading to #14588. This fixes it by
      creating a `hintBangPat` function to perform this check, and
      sprinkling it in the right places.
      
      Test Plan: make test TEST=T14588
      
      Reviewers: bgamari, alanz, simonpj
      
      Reviewed By: bgamari, simonpj
      
      Subscribers: rwbarton, thomie, mpickering, carter
      
      GHC Trac Issues: #14588
      
      Differential Revision: https://phabricator.haskell.org/D4270
      9caf40e9
  3. 07 Dec, 2017 1 commit
    • Simon Peyton Jones's avatar
      Refactor ConDecl: Trac #14529 · fa29df02
      Simon Peyton Jones authored
      This patch refactors HsDecls.ConDecl.  Specifically
      
      * ConDeclGADT was horrible, with all the information hidden
        inside con_res_ty.  Now it's kept separate, as it should be.
      
      * ConDeclH98: use [LHsTyVarBndr] instead of LHsQTyVars for the
        existentials. There is no implicit binding here.
      
      * Add a field con_forall to both ConDeclGADT and ConDeclH98
        which says if there is an explicit user-written forall.
      
      * Field renamings in ConDecl
           con_cxt     to con_mb_cxt
           con_details to con_args
      
      There is an accompanying submodule update to Haddock.
      
      Also the following change turned out to remove a lot of clutter:
      
      * add a smart constructor for HsAppsTy, namely mkHsAppsTy,
        and use it consistently. This avoids a lot of painful pattern
        matching for the common singleton case.
      
      Two api-annotation tests (T10278, and T10399) are broken, hence marking
      them as expect_broken(14529).  Alan is going to fix them, probably by
      changing the con_forall field to
         con_forall :: Maybe SrcSpan
      instead of Bool
      fa29df02
  4. 21 Nov, 2017 1 commit
    • Ben Gamari's avatar
      Revert "trees that grow" work · 314bc314
      Ben Gamari authored
      As documented in #14490, the Data instances currently blow up
      compilation time by too much to stomach. Alan will continue working on
      this in a branch and we will perhaps merge to 8.2 before 8.2.1 to avoid
      having to perform painful cherry-picks in 8.2 minor releases.
      
      Reverts haddock submodule.
      
      This reverts commit 47ad6578.
      This reverts commit e3ec2e7a.
      This reverts commit 438dd1cb.
      This reverts commit 0ff152c9.
      314bc314
  5. 11 Nov, 2017 1 commit
  6. 08 Nov, 2017 1 commit
  7. 07 Nov, 2017 2 commits
  8. 02 Nov, 2017 1 commit
  9. 25 Oct, 2017 2 commits
    • Alec Theriault's avatar
      Fix a bug in 'alexInputPrevChar' · 821adee1
      Alec Theriault authored
      The lexer hacks around unicode by squishing any character into a 'Word8'
      and then storing the actual character in its state. This happens at
      'alexGetByte'.
      
      That is all and well, but we ought to be careful that the characters we
      retrieve via 'alexInputPrevChar' also fit this convention.
      
      In fact, #13986 exposes nicely what can go wrong: the regex in the left
      context of the type application rule uses the '$idchar' character set
      which relies on the unicode hack. However, a left context corresponds
      to a call to 'alexInputPrevChar', and we end up passing full blown
      unicode characters to '$idchar', despite it not being equipped to deal
      with these.
      
      Test Plan: Added a regression test case
      
      Reviewers: austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #13986
      
      Differential Revision: https://phabricator.haskell.org/D4105
      821adee1
    • Ben Gamari's avatar
      typecheck: Clarify errors mentioned in #14385 · bf83435b
      Ben Gamari authored
      bf83435b
  10. 06 Oct, 2017 1 commit
  11. 15 Sep, 2017 1 commit
    • Alan Zimmerman's avatar
      Renamer now preserves location for IEThingWith list items · 9498c50e
      Alan Zimmerman authored
      Prior to this, in the RenamedSource for
      
          module Renaming.RenameInExportedType
            (
            MyType (NT)
            ) where
      
          data MyType = MT Int | NT
      
      The (NT) was given the location of MyType earlier on the line in the
      export list.
      
      Also the location was discarded for any field labels, and replaced with
      a `noLoc`.
      
      Test Plan: ./validate
      
      Reviewers: bgamari, austin
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #14189
      
      Differential Revision: https://phabricator.haskell.org/D3968
      9498c50e
  12. 13 Sep, 2017 1 commit
  13. 05 Sep, 2017 1 commit
    • Ryan Scott's avatar
      Implicitly bind kind variables in type family instance RHSes when it's sensible · 0829821a
      Ryan Scott authored
      Summary:
      Before, there was a discrepancy in how GHC renamed type synonyms as
      opposed to type family instances. That is, GHC would accept definitions like
      this one:
      
      ```lang=haskell
      type T = (Nothing :: Maybe a)
      ```
      
      However, it would not accept a very similar type family instance:
      
      ```lang=haskell
      type family   T :: Maybe a
      type instance T = (Nothing :: Maybe a)
      ```
      
      The primary goal of this patch is to bring the renaming of type family
      instances up to par with that of type synonyms, causing the latter definition
      to be accepted, and fixing #14131.
      
      In particular, we now allow kind variables on the right-hand sides of type
      (and data) family instances to be //implicitly// bound by LHS type (or kind)
      patterns (as opposed to type variables, which must always be explicitly
      bound by LHS type patterns only). As a consequence, this allows programs
      reported in #7938 and #9574 to typecheck, whereas before they would
      have been rejected.
      
      Implementation-wise, there isn't much trickery involved in making this happen.
      We simply need to bind additional kind variables from the RHS of a type family
      in the right place (in particular, see `RnSource.rnFamInstEqn`, which has
      undergone a minor facelift).
      
      While doing this has the upside of fixing #14131, it also made it easier to
      trigger #13985, so I decided to fix that while I was in town. This was
      accomplished by a careful blast of `reportFloatingKvs` in `tcFamTyPats`.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, goldfire, austin, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #13985, #14131
      
      Differential Revision: https://phabricator.haskell.org/D3872
      0829821a
  14. 29 Aug, 2017 2 commits
    • Ryan Scott's avatar
      Refactor type family instance abstract syntax declarations · 895a7650
      Ryan Scott authored
      This implements @simonpj's suggested refactoring of the abstract syntax
      for type/data family instances (from
      https://ghc.haskell.org/trac/ghc/ticket/14131#comment:9). This combines
      the previously separate `TyFamEqn` and `DataFamInstDecl` types into a
      single `FamEqn` datatype. This also factors the `HsImplicitBndrs` out of
      `HsTyPats` in favor of putting them just outside of `FamEqn` (as opposed
      to before, where all of the implicit binders were embedded inside of
      `TyFamEqn`/`DataFamInstDecl`). Finally, along the way I noticed that
      `dfid_fvs` and `tfid_fvs` were completely unused, so I removed them.
      
      Aside from some changes in parser test output, there is no change in
      behavior.
      
      Requires a Haddock submodule commit from my fork (at
      https://github.com/RyanGlScott/haddock/commit/815d2deb9c0222c916becccf84
      64b740c26255fd)
      
      Test Plan: ./validate
      
      Reviewers: simonpj, austin, goldfire, bgamari, alanz
      
      Reviewed By: bgamari
      
      Subscribers: mpickering, goldfire, rwbarton, thomie, simonpj
      
      GHC Trac Issues: #14131
      
      Differential Revision: https://phabricator.haskell.org/D3881
      895a7650
    • David Feuer's avatar
      Make parsed AST dump output lazily · 29da01e0
      David Feuer authored
      Previously, `showAstData` produced a `String`. That `String` would
      then be converted to a `Doc` using `text` to implement
      `-ddump-parsed-ast`. But rendering `text` calculates the length
      of the `String` before doing anything else. Since the AST can be
      very large, this was bad: the whole dump string (potentially hundreds
      of millions of `Char`s) was accumulated in memory.
      
      Now, `showAstData` produces a `Doc` directly, which seems to work
      a lot better. As an extra bonus, the code is simpler and cleaner.
      The formatting has changed a bit, as the previous ad hoc approach
      didn't really match the pretty printer too well. If someone cares
      enough to request adjustments, we can surely make them.
      
      Reviewers: austin, bgamari, mpickering, alanz
      
      Reviewed By: bgamari
      
      Subscribers: mpickering, rwbarton, thomie
      
      GHC Trac Issues: #14161
      
      Differential Revision: https://phabricator.haskell.org/D3894
      29da01e0
  15. 31 Jul, 2017 1 commit
    • Simon Peyton Jones's avatar
      Improve the desugaring of -XStrict · 46368868
      Simon Peyton Jones authored
      Trac #14035 showed that -XStrict was generating some TERRIBLE
      desugarings, espcially for bindings with INLINE pragmas. Reason: with
      -XStrict, all AbsBinds (even for non-recursive functions) went via the
      general-case deguaring for AbsBinds, namely "generate a tuple and
      select from it", even though in this case there was only one variable
      in the tuple.  And that in turn interacts terribly badly with INLINE
      pragmas.
      
      This patch cleans things up:
      
      * I killed off AbsBindsSig completely, in favour of a boolean flag
        abs_sig in AbsBinds.  See Note [The abs_sig field of AbsBinds]
      
        This allowed me to delete lots of code; and instance-method
        declarations can enjoy the benefits too.  (They could have
        before, but no one had changed them to use AbsBindsSig.)
      
      * I refactored all the AbsBinds handling in DsBinds into a new
        function DsBinds.dsAbsBinds.  This allowed me to handle the
        strict case uniformly
      46368868
  16. 28 Jul, 2017 1 commit
    • Simon Peyton Jones's avatar
      Do not discard insolubles in implications · 452755de
      Simon Peyton Jones authored
      Trac #14000 showed up two errors
      
      * In TcRnTypes.dropInsolubles we dropped all implications, which
        might contain the very insolubles we wanted to keep.  This was
        an outright error, and is why the out-of-scope error was actually
        lost altogether in Trac #14000
      
      * In TcSimplify.simplifyInfer, if there are definite (insoluble)
        errors, it's better to suppress the following ambiguity test,
        because the type may be bogus anyway.  See TcSimplify
        Note [Quantification with errors].  This fix seems a bit clunky,
        but it'll do for now.
      452755de
  17. 11 Jul, 2017 1 commit
    • Ryan Scott's avatar
      Fix #13948 by being pickier about when to suggest DataKinds · ba46e63f
      Ryan Scott authored
      Commit 343cb32d (#13568) made GHC a bit
      too cavalier in suggesting when data constructors are in scope (and
      suggesting the use of `DataKinds`). This tones down the suggestions so
      that `DataKinds` is only suggested if a data constructor of that name is
      actually in scope (previously, it would always suggest, even if it was
      out of scope).
      
      Fixes #13948.
      
      Test Plan: ./validate
      
      Reviewers: mpickering, austin, bgamari
      
      Reviewed By: mpickering
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #13948
      
      Differential Revision: https://phabricator.haskell.org/D3719
      ba46e63f
  18. 29 Jun, 2017 1 commit
  19. 27 Jun, 2017 1 commit
    • Ben Gamari's avatar
      Treat banged bindings as FunBinds · 6567c815
      Ben Gamari authored
      This is another attempt at resolving #13594 by treating strict variable
      binds as FunBinds instead of PatBinds (as suggested in comment:1).
      
      Test Plan: Validate
      
      Reviewers: austin, alanz
      
      Subscribers: rwbarton, thomie, mpickering
      
      GHC Trac Issues: #13594
      
      Differential Revision: https://phabricator.haskell.org/D3670
      6567c815
  20. 15 May, 2017 1 commit
  21. 12 May, 2017 1 commit
    • Ben Gamari's avatar
      Revert "Treat banged bindings as FunBinds" · 3032ae81
      Ben Gamari authored
      This partially reverts commit 37299536 as it
      doesn't actually fix #13594. Namely it does not revert the mkPrefixFunRhs
      refactoring since this is rather independent from the functional changes.
      
      Going to try again with a whole working patch
      3032ae81
  22. 11 May, 2017 2 commits
    • Ben Gamari's avatar
      Fix up tests for #13594 · 3e79fe42
      Ben Gamari authored
      This adds the GHCi variant of the failing program in #13594. Also, I
      inadvertently changed the T13594 test previously introduced in a way that made
      it no longer faithfully test the ticket as written. Fix this.
      3e79fe42
    • mrkgnao's avatar
      Fix incorrect ambiguity error on identically-named data constructors · 1381c142
      mrkgnao authored
      Given multiple in-scope constructors with the same name, say `A`, and a
      function of type `A -> Int`, say, the compiler reports both a "type `A`
      is not in scope" and (incorrectly) an ambiguity error. The latter
      shouldn't be there if `DataKinds` isn't enabled.
      
      This issue was recommended to me by @mpickering as a suitable first
      task, and the fix was also outlined in the original Trac ticket. It
      involved a simple reordering of the steps taken in `lookup_demoted` in
      `RnEnv.hs`. The fix is to make the `DataKinds` check happen earlier,
      ensuring that the ambiguity check doesn't happen at all if we know the
      constructors couldn't have been promoted.
      Signed-off-by: mrkgnao's avatarSoham Chowdhury <chow.soham@gmail.com>
      
      Reviewers: mpickering, austin, bgamari
      
      Reviewed By: mpickering, bgamari
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #13568
      
      Differential Revision: https://phabricator.haskell.org/D3547
      1381c142
  23. 09 May, 2017 1 commit
    • Ben Gamari's avatar
      Treat banged bindings as FunBinds · 37299536
      Ben Gamari authored
      This reworks the HsSyn representation to make banged variable patterns
      (e.g. !x = e) be represented as FunBinds instead of PatBinds, adding a flag to
      FunRhs to record the bang.
      
      Fixes #13594.
      
      Reviewers: austin, goldfire, alanz, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: simonpj, rwbarton, thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D3525
      37299536
  24. 08 May, 2017 1 commit
  25. 29 Mar, 2017 1 commit
  26. 26 Mar, 2017 1 commit
  27. 14 Mar, 2017 1 commit
    • Richard Eisenberg's avatar
      Fix #13337. · e0c433c8
      Richard Eisenberg authored
      The big change is the introduction of solveSomeEqualities. This
      is just like solveEqualities, but it doesn't fail if there are unsolved
      equalities when it's all done. Anything unsolved is re-emitted. This
      is appropriate if we are not kind-generalizing, so this new form
      is used when decideKindGeneralizationPlan says not to.
      
      We initially thought that any use of solveEqualities would be tied
      to kind generalization, but this isn't true. For example, we need
      to solveEqualities a bunch in the "tc" pass in TcTyClsDecls (which
      is really desugaring). These equalities are all surely going to be
      soluble (if they weren't the "kc" pass would fail), but we still
      need to solve them again. Perhaps if the "kc" pass produced type-
      checked output that is then desugared, solveEqualities really would
      be tied only to kind generalization.
      
      Updates haddock submodule.
      
      Test Plan: ./validate, typecheck/should_compile/T13337
      
      Reviewers: simonpj, bgamari, austin
      
      Reviewed By: simonpj
      
      Subscribers: RyanGlScott, rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3315
      e0c433c8
  28. 13 Mar, 2017 2 commits
  29. 10 Mar, 2017 2 commits
    • Simon Peyton Jones's avatar
      Improve error messages for skolems · 48d1866e
      Simon Peyton Jones authored
      In error messages like this
          • Couldn't match type ‘c’ with ‘f0 (a -> b)’
            ‘c’ is a rigid type variable bound by
              the type signature for:
                f :: ((a -> b) -> b) -> forall c. c -> a
      
      we need to take case both to actually show that 'forall c',
      and to make sure that its name lines with the 'c' in the
      error message.
      
      This has been shaky for some time, and this commit puts it on solid
      ground.  See TcRnTypes: Note [SigSkol SkolemInfo]
      
      The main changes are
      
      * SigSkol gets an extra field that records the way in which the
        type signature was skolemised.
      
      * The type in SigSkol is now the /un/-skolemised version
      
      * pprSkolemInfo uses the info to make the tidy type line up
        nicely
      
      Lots of error message wibbles!
      48d1866e
    • Simon Peyton Jones's avatar
      Fix TcSimplify.decideQuantification for kind variables · 7e96526a
      Simon Peyton Jones authored
      TcSimplify.decideQuantification was doing the Wrong Thing when
      "growing" the type variables to quantify over. We were trying to do
      this on a tyvar set where we'd split off the dependent type varaibles;
      and we just got it wrong.  A kind variable wasn't being generalised
      properly, with confusing knock on consequences.
      
      All this led to Trac #13371 and Trac #13393.
      
      This commit tidies it all up:
      
      * The type TcDepVars is renamed as CandidateQTvs;
        and splitDepVarsOfType to candidateQTyVarsOfType
      
      * The code in TcSimplify.decideQuantification is simpler.
        It no longer does the tricky "grow" stuff over TcDepVars.
        Instead it use ordinary VarSets (thereby eliminating the
        nasty growThetaTyVarsDSet) and uses that to filter the
        result of candidateQTyVarsOfType.
      
      * I documented that candidateQTyVarsOfType returns the type
        variables in a good order in which to quantify, and rewrote
        it to use an accumulator pattern, so that we would predicatably
        get left-to-right ordering.
      
      In doing all this I also made UniqDFM behave a little more nicely:
      
      * When inserting an element that is there already, keep the old tag,
        while still overwriting with the new value.
      
      * This means that when doing udfmToList we get back elements in the
        order they were originally inserted, rather than in reverse order.
      
      It's not a big deal, but in a subsequent commit I use it to improve
      the order of type variables in inferred types.
      
      All this led to a lot of error message wibbles:
       - changing the order of quantified variables
       - changing the order in which instances are listed in GHCi
       - changing the tidying of variables in typechecker erors
      
      There's a submodule update for 'array' because one of its tests
      has an error-message change.
      
      I may not have associated all of them with the correct commit.
      7e96526a
  30. 06 Mar, 2017 1 commit
  31. 03 Mar, 2017 4 commits
    • Ben Gamari's avatar
      Produce KindReps for common kinds in GHC.Types · c1dacb8a
      Ben Gamari authored
      Unfortunately this comes with a fair bit of implementation cost. Perhaps
      some refactoring would help, but in the interest of getting 8.2 out the
      door I'm pushing as-is.
      
      While this doesn't have nearly the effect on compiler allocations
      that D3166 has, it's still nothing to sneeze at. nofib shows,
      ```
      ------------------------------------------------------------------------
              Program               master           D3166            D3219
      ------------------------------------------------------------------------
              -1 s.d.                -----          -3.555%          -4.081%
              +1 s.d.                -----          +1.937%          +1.593%
              Average                -----          -0.847%          -1.285%
      ```
      
      Test Plan: Validate
      
      Reviewers: austin
      
      Subscribers: thomie, simonmar
      
      Differential Revision: https://phabricator.haskell.org/D3219
      c1dacb8a
    • Ben Gamari's avatar
      TcTypeable: Try to reuse KindReps · a694cee7
      Ben Gamari authored
      Here we rework the TcTypeable implementation to reuse KindRep bindings
      when possible. This is an attempt at minimizing the impact of Typeable
      binding generation by reducing the number of bindings that we produce.
      
      It turns out that this produces some pretty reasonable compiler
      allocations improvements. It seems to erase most of the increases
      initially introduced by TTypeable in the testsuite. Moreover, nofib
      shows,
      ```
              -1 s.d.                -----          -3.555%
              +1 s.d.                -----          +1.937%
              Average                -----          -0.847%
      ```
      
      Here are a few of the high-scorers (ignore last column, which is for
      D3219),
      ```
      veritas
                Types             88800920         -18.945%         -21.480%
      
      veritas
              Tactics            540766744         -27.256%         -27.338%
      
      sched
                 Main            567013384          -4.947%          -5.358%
      
      listcompr
                 Main            532300000          -4.273%          -4.572%
      
      listcopy
                 Main            537785392          -4.382%          -4.635%
      
      anna
             BaseDefs           1984225032         -10.639%         -10.832%
      
      ```
      as expected, these tend to be modules with either very many or very
      large types.
      
      Test Plan: Validate
      
      Reviewers: austin, dfeuer
      
      Subscribers: simonmar, dfeuer, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3166
      a694cee7
    • Ben Gamari's avatar
      testsuite: Fix output due to recent COMPLETE changes · ca538b84
      Ben Gamari authored
      It's unclear why this didn't show up in my initial local validation. Oh
      well.
      ca538b84
    • ruperthorlick's avatar
      Changed parser message for RankNTypes (#12811) · 488a9daa
      ruperthorlick authored
      Added a check for whether RankNTypes is enabled
      and changed error message accordingly
      
      Reviewers: austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D3262
      488a9daa