1. 21 Mar, 2019 1 commit
    • Ryan Scott's avatar
      Reject nested predicates in impredicativity checking · 8d18a873
      Ryan Scott authored
      When GHC attempts to unify a metavariable with a type containing
      foralls, it will be rejected as an occurrence of impredicativity.
      GHC was /not/ extending the same treatment to predicate types, such
      as in the following (erroneous) example from #11514:
      
      ```haskell
      foo :: forall a. (Show a => a -> a) -> ()
      foo = undefined
      ```
      
      This will attempt to instantiate `undefined` at
      `(Show a => a -> a) -> ()`, which is impredicative. This patch
      catches impredicativity arising from predicates in this fashion.
      
      Since GHC is pickier about impredicative instantiations, some test
      cases needed to be updated to be updated so as not to fall afoul of
      the new validity check. (There were a surprising number of
      impredicative uses of `undefined`!) Moreover, the `T14828` test case
      now has slightly less informative types shown with `:print`. This is
      due to a a much deeper issue with the GHCi debugger (see #14828).
      
      Fixes #11514.
      8d18a873
  2. 15 Mar, 2019 1 commit
  3. 08 Mar, 2019 1 commit
    • Sylvain Henry's avatar
      TH: support raw bytes literals (#14741) · 224a6b86
      Sylvain Henry authored
      GHC represents String literals as ByteString internally for efficiency
      reasons. However, until now it wasn't possible to efficiently create
      large string literals with TH (e.g. to embed a file in a binary, cf #14741):
      TH code had to unpack the bytes into a [Word8] that GHC then had to re-pack
      into a ByteString.
      
      This patch adds the possibility to efficiently create a "string" literal
      from raw bytes. We get the following compile times for different sizes
      of TH created literals:
      
      || Size || Before || After  || Gain ||
      || 30K  || 2.307s || 2.299  || 0%   ||
      || 3M   || 3.073s || 2.400s || 21%  ||
      || 30M  || 8.517s || 3.390s || 60%  ||
      
      Ticket #14741 can be fixed if the original code uses this new TH feature.
      224a6b86
  4. 01 Mar, 2019 1 commit
    • Ryan Scott's avatar
      Visible dependent quantification · c26d299d
      Ryan Scott authored
      This implements GHC proposal 35
      (https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0035-forall-arrow.rst)
      by adding the ability to write kinds with
      visible dependent quantification (VDQ).
      
      Most of the work for supporting VDQ was actually done _before_ this
      patch. That is, GHC has been able to reason about kinds with VDQ for
      some time, but it lacked the ability to let programmers directly
      write these kinds in the source syntax. This patch is primarly about
      exposing this ability, by:
      
      * Changing `HsForAllTy` to add an additional field of type
        `ForallVisFlag` to distinguish between invisible `forall`s (i.e,
        with dots) and visible `forall`s (i.e., with arrows)
      * Changing `Parser.y` accordingly
      
      The rest of the patch mostly concerns adding validity checking to
      ensure that VDQ is never used in the type of a term (as permitting
      this would require full-spectrum dependent types). This is
      accomplished by:
      
      * Adding a `vdqAllowed` predicate to `TcValidity`.
      * Introducing `splitLHsSigmaTyInvis`, a variant of `splitLHsSigmaTy`
        that only splits invisible `forall`s. This function is used in
        certain places (e.g., in instance declarations) to ensure that GHC
        doesn't try to split visible `forall`s (e.g., if it tried splitting
        `instance forall a -> Show (Blah a)`, then GHC would mistakenly
        allow that declaration!)
      
      This also updates Template Haskell by introducing a new `ForallVisT`
      constructor to `Type`.
      
      Fixes #16326. Also fixes #15658 by documenting this feature in the
      users' guide.
      c26d299d
  5. 24 Feb, 2019 1 commit
  6. 12 Feb, 2019 1 commit
    • Ryan Scott's avatar
      Fix #16293 by cleaning up Proxy# infelicities · 012257c1
      Ryan Scott authored
      This bug fixes three problems related to `Proxy#`/`proxy#`:
      
      1. Reifying it with TH claims that the `Proxy#` type constructor has
         two arguments, but that ought to be one for consistency with
         TH's treatment for other primitive type constructors like `(->)`.
         This was fixed by just returning the number of
         `tyConVisibleTyVars` instead of using `tyConArity` (which includes
         invisible arguments).
      2. The role of `Proxy#`'s visible argument was hard-coded as nominal.
         Easily fixed by changing it to phantom.
      3. The visibility of `proxy#`'s kind argument was specified, which
         is different from the `Proxy` constructor (which treats it as
         inferred). Some minor refactoring in `proxyHashId` fixed ths up.
      
         Along the way, I had to introduce a `mkSpecForAllTy` function, so
         I did some related Haddock cleanup in `Type`, where that function
         lives.
      012257c1
  7. 10 Feb, 2019 1 commit
    • Matthew Pickering's avatar
      Capture and simplify constraints arising from running typed splices · a48753bd
      Matthew Pickering authored
      This fixes a regression caused by #15471 where splicing in a trivial
      program such as `[|| return () ||]` would fail as the dictionary for
      `return` would never get bound in the module containing the splice.
      
      Arguably this is symptomatic of a major problem affecting TTH where we
      serialise renamed asts and then retype check them. The reference to the
      dictionary should be fully determined at the quote site so that splicing
      doesn't have to solve any implicits at all. It's a coincidence this
      works due to coherence but see #15863 and #15865 for examples where
      things do go very wrong.
      
      Fixes #16195
      a48753bd
  8. 08 Feb, 2019 1 commit
  9. 30 Jan, 2019 3 commits
  10. 28 Jan, 2019 1 commit
    • Ryan Scott's avatar
      Use sigPrec in more places in Convert and HsUtils · b1e569a5
      Ryan Scott authored
      Trac #16183 was caused by TH conversion (in `Convert`) not properly
      inserting parentheses around occurrences of explicit signatures where
      appropriate, such as in applications, function types, and type family
      equations. Solution: use `parenthesizeHsType sigPrec` in these
      places. While I was in town, I also updated `nlHsFunTy` to do the
      same thing.
      b1e569a5
  11. 23 Jan, 2019 1 commit
  12. 21 Jan, 2019 1 commit
  13. 11 Jan, 2019 1 commit
    • Matthew Pickering's avatar
      Run typed splices in the zonker · c2455e64
      Matthew Pickering authored
      Summary:
      This fixes #15471
      
      In the typechecker we check that the splice has the right type but we
      crucially don't zonk the generated expression. This is because we might
      end up unifying type variables from outer scopes later on.
      
      Reviewers: simonpj, goldfire, bgamari
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15471
      
      Differential Revision: https://phabricator.haskell.org/D5286
      c2455e64
  14. 06 Jan, 2019 1 commit
  15. 03 Jan, 2019 1 commit
    • My Nguyen's avatar
      Visible kind application · 17bd1635
      My Nguyen authored
      Summary:
      This patch implements visible kind application (GHC Proposal 15/#12045), as well as #15360 and #15362.
      It also refactors unnamed wildcard handling, and requires that type equations in type families in Template Haskell be
      written with full type on lhs. PartialTypeSignatures are on and warnings are off automatically with visible kind
      application, just like in term-level.
      
      There are a few remaining issues with this patch, as documented in
      ticket #16082.
      
      Includes a submodule update for Haddock.
      
      Test Plan: Tests T12045a/b/c/TH1/TH2, T15362, T15592a
      
      Reviewers: simonpj, goldfire, bgamari, alanz, RyanGlScott, Iceland_jack
      
      Subscribers: ningning, Iceland_jack, RyanGlScott, int-index, rwbarton, mpickering, carter
      
      GHC Trac Issues: `#12045`, `#15362`, `#15592`, `#15788`, `#15793`, `#15795`, `#15797`, `#15799`, `#15801`, `#15807`, `#15816`
      
      Differential Revision: https://phabricator.haskell.org/D5229
      17bd1635
  16. 29 Dec, 2018 1 commit
  17. 24 Dec, 2018 1 commit
  18. 22 Dec, 2018 1 commit
  19. 11 Dec, 2018 1 commit
  20. 07 Dec, 2018 1 commit
    • Simon Peyton Jones's avatar
      Wibble to Taming the Kind Inference Monster · 5b7ca039
      Simon Peyton Jones authored
      I had allowed rename/should_fail/T15828 (Trac #15828) to regress a bit.
      The main payload of this patch is to fix that problem, at the cost of
      more contortions in checkConsistentFamInst.  Oh well, at least they are
      highly localised.
      
      I also update the -ddump-types code in TcRnDriver to print out some
      more expicit information about each type constructor, thus instead of
      
         DF{3} :: forall k. * -> k -> *
      
      we get
      
         data family DF{3} :: forall k. * -> k -> *
      
      Remember, this is debug-printing only.  This change is the reason
      that so many .stderr files change.
      5b7ca039
  21. 03 Dec, 2018 1 commit
    • Ryan Scott's avatar
      Fix embarrassing infinite loop in pprParendType · 89d80921
      Ryan Scott authored
      Summary:
      `pprParendType` was missing an explicit case for
      `EqualityT`, which caused it to fall through to a catch-all case
      that invokes `ppr`. But `ppr` itself does not have a case for a
      partial application of `EqualityT`, so //it// falls back to
      `pprParendType`, resulting in an infinite loop!
      
      The fix is simple: add a case for `EqualityT` in `pprParendType`.
      While I was in the neighborhood, I removed the catch-call case in
      `pprParendType` to make this sort of mistake less likely to happen
      in the future.
      
      Test Plan: make test TEST=T15985
      
      Reviewers: bgamari, monoidal, simonpj
      
      Reviewed By: monoidal, simonpj
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15985
      
      Differential Revision: https://phabricator.haskell.org/D5403
      89d80921
  22. 30 Nov, 2018 1 commit
    • Alec Theriault's avatar
      Add 'Lift' instances for 'NonEmpty' and 'Void' · 47875bd4
      Alec Theriault authored
      Summary:
      Since 'NonEmpty' and 'Void' are now part of 'base', it makes
      sense that we put 'Lift' instances for them in 'template-haskell'.
      Not doing so is going to force users to define their own (possibly
      colliding) orphan instances downstream.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, bgamari, RyanGlScott
      
      Reviewed By: RyanGlScott
      
      Subscribers: RyanGlScott, rwbarton, carter
      
      GHC Trac Issues: #15961
      
      Differential Revision: https://phabricator.haskell.org/D5391
      47875bd4
  23. 29 Nov, 2018 1 commit
    • Simon Peyton Jones's avatar
      Taming the Kind Inference Monster · 2257a86d
      Simon Peyton Jones authored
      My original goal was (Trac #15809) to move towards using level numbers
      as the basis for deciding which type variables to generalise, rather
      than searching for the free varaibles of the environment.  However
      it has turned into a truly major refactoring of the kind inference
      engine.
      
      Let's deal with the level-numbers part first:
      
      * Augment quantifyTyVars to calculate the type variables to
        quantify using level numbers, and compare the result with
        the existing approach.  That is; no change in behaviour,
        just a WARNing if the two approaches give different answers.
      
      * To do this I had to get the level number right when calling
        quantifyTyVars, and this entailed a bit of care, especially
        in the code for kind-checking type declarations.
      
      * However, on the way I was able to eliminate or simplify
        a number of calls to solveEqualities.
      
      This work is incomplete: I'm not /using/ level numbers yet.
      When I subsequently get rid of any remaining WARNings in
      quantifyTyVars, that the level-number answers differ from
      the current answers, then I can rip out the current
      "free vars of the environment" stuff.
      
      Anyway, this led me into deep dive into kind inference for type and
      class declarations, which is an increasingly soggy part of GHC.
      Richard already did some good work recently in
      
         commit 5e45ad10
         Date:   Thu Sep 13 09:56:02 2018 +0200
      
          Finish fix for #14880.
      
          The real change that fixes the ticket is described in
          Note [Naughty quantification candidates] in TcMType.
      
      but I kept turning over stones. So this patch has ended up
      with a pretty significant refactoring of that code too.
      
      Kind inference for types and classes
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      * Major refactoring in the way we generalise the inferred kind of
        a TyCon, in kcTyClGroup.  Indeed, I made it into a new top-level
        function, generaliseTcTyCon.  Plus a new Note to explain it
        Note [Inferring kinds for type declarations].
      
      * We decided (Trac #15592) not to treat class type variables specially
        when dealing with Inferred/Specified/Required for associated types.
        That simplifies things quite a bit. I also rewrote
        Note [Required, Specified, and Inferred for types]
      
      * Major refactoring of the crucial function kcLHsQTyVars:
        I split it into
             kcLHsQTyVars_Cusk  and  kcLHsQTyVars_NonCusk
        because the two are really quite different. The CUSK case is
        almost entirely rewritten, and is much easier because of our new
        decision not to treat the class variables specially
      
      * I moved all the error checks from tcTyClTyVars (which was a bizarre
        place for it) into generaliseTcTyCon and/or the CUSK case of
        kcLHsQTyVars.  Now tcTyClTyVars is extremely simple.
      
      * I got rid of all the all the subtleties in tcImplicitTKBndrs. Indeed
        now there is no difference between tcImplicitTKBndrs and
        kcImplicitTKBndrs; there is now a single bindImplicitTKBndrs.
        Same for kc/tcExplicitTKBndrs.  None of them monkey with level
        numbers, nor build implication constraints.  scopeTyVars is gone
        entirely, as is kcLHsQTyVarBndrs. It's vastly simpler.
      
        I found I could get rid of kcLHsQTyVarBndrs entirely, in favour of
        the bnew bindExplicitTKBndrs.
      
      Quantification
      ~~~~~~~~~~~~~~
      * I now deal with the "naughty quantification candidates"
        of the previous patch in candidateQTyVars, rather than in
        quantifyTyVars; see Note [Naughty quantification candidates]
        in TcMType.
      
        I also killed off closeOverKindsCQTvs in favour of the same
        strategy that we use for tyCoVarsOfType: namely, close over kinds
        at the occurrences.
      
        And candidateQTyVars no longer needs a gbl_tvs argument.
      
      * Passing the ContextKind, rather than the expected kind itself,
        to tc_hs_sig_type_and_gen makes it easy to allocate the expected
        result kind (when we are in inference mode) at the right level.
      
      Type families
      ~~~~~~~~~~~~~~
      * I did a major rewrite of the impenetrable tcFamTyPats. The result
        is vastly more comprehensible.
      
      * I got rid of kcDataDefn entirely, quite a big function.
      
      * I re-did the way that checkConsistentFamInst works, so
        that it allows alpha-renaming of invisible arguments.
      
      * The interaction of kind signatures and family instances is tricky.
          Type families: see Note [Apparently-nullary families]
          Data families: see Note [Result kind signature for a data family instance]
                         and Note [Eta-reduction for data families]
      
      * The consistent instantation of an associated type family is tricky.
        See Note [Checking consistent instantiation] and
            Note [Matching in the consistent-instantation check]
        in TcTyClsDecls.  It's now checked in TcTyClsDecls because that is
        when we have the relevant info to hand.
      
      * I got tired of the compromises in etaExpandFamInst, so I did the
        job properly by adding a field cab_eta_tvs to CoAxBranch.
        See Coercion.etaExpandCoAxBranch.
      
      tcInferApps and friends
      ~~~~~~~~~~~~~~~~~~~~~~~
      * I got rid of the mysterious and horrible ClsInstInfo argument
        to tcInferApps, checkExpectedKindX, and various checkValid
        functions.  It was horrible!
      
      * I got rid of [Type] result of tcInferApps.  This list was used
        only in tcFamTyPats, when checking the LHS of a type instance;
        and if there is a cast in the middle, the list is meaningless.
        So I made tcInferApps simpler, and moved the complexity
        (not much) to tcInferApps.
      
        Result: tcInferApps is now pretty comprehensible again.
      
      * I refactored the many function in TcMType that instantiate skolems.
      
      Smaller things
      
      * I rejigged the error message in checkValidTelescope; I think it's
        quite a bit better now.
      
      * checkValidType was not rejecting constraints in a kind signature
           forall (a :: Eq b => blah). blah2
        That led to further errors when we then do an ambiguity check.
        So I make checkValidType reject it more aggressively.
      
      * I killed off quantifyConDecl, instead calling kindGeneralize
        directly.
      
      * I fixed an outright bug in tyCoVarsOfImplic, where we were not
        colleting the tyvar of the kind of the skolems
      
      * Renamed ClsInstInfo to AssocInstInfo, and made it into its
        own data type
      
      * Some fiddling around with pretty-printing of family
        instances which was trickier than I thought.  I wanted
        wildcards to print as plain "_" in user messages, although
        they each need a unique identity in the CoAxBranch.
      
      Some other oddments
      
      * Refactoring around the trace messages from reportUnsolved.
      * A bit of extra tc-tracing in TcHsSyn.commitFlexi
      
      This patch fixes a raft of bugs, and includes tests for them.
      
       * #14887
       * #15740
       * #15764
       * #15789
       * #15804
       * #15817
       * #15870
       * #15874
       * #15881
      2257a86d
  24. 22 Nov, 2018 1 commit
  25. 08 Nov, 2018 1 commit
    • Ryan Scott's avatar
      Fix #15845 by defining etaExpandFamInstLHS and using it · 63a81707
      Ryan Scott authored
      Summary:
      Both #9692 and #14179 were caused by GHC being careless
      about using eta-reduced data family instance axioms. Each of those
      tickets were fixed by manually whipping up some code to eta-expand
      the axioms. The same sort of issue has now caused #15845, so I
      figured it was high time to factor out the code that each of these
      fixes have in common.
      
      This patch introduces the `etaExpandFamInstLHS` function, which takes
      a family instance's type variables, LHS types, and RHS type, and
      returns type variables and LHS types that have been eta-expanded if
      necessary, in the case of a data family instance. (If it's a type
      family instance, `etaExpandFamInstLHS` just returns the supplied type
      variables and LHS types unchanged).
      
      Along the way, I noticed that many references to
      `Note [Eta reduction for data families]` (in `FamInstEnv`) had
      slightly bitrotted (they either referred to a somewhat different
      name, or claimed that the Note lived in a different module), so
      I took the liberty of cleaning those up.
      
      Test Plan: make test TEST="T9692 T15845"
      
      Reviewers: goldfire, bgamari
      
      Reviewed By: goldfire
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15845
      
      Differential Revision: https://phabricator.haskell.org/D5294
      63a81707
  26. 29 Oct, 2018 2 commits
    • Ryan Scott's avatar
      Fix #15815 by parenthesizing the arguments to infix ~ · b8a797ec
      Ryan Scott authored
      An unfortunate consequence of commit
      b9483981 (`Remove HsEqTy and XEqTy`)
      is infix uses of `~` in TH quotes now desugar differently than
      before. In particular, we have that:
      
      ```haskell
      a ~ (Int -> Int)
      ```
      
      Now desugars to:
      
      ```haskell
      HsOpTy a (~) (HsOpTy Int (->) Int)
      ```
      
      Which GHC interprets as being:
      
      ```haskell
      a ~ Int -> Int
      ```
      
      Or, equivalently:
      
      ```haskell
      (a ~ Int) -> Int
      ```
      
      Which is different than what was intended! This is the cause
      of #15815.
      
      All of this has revealed that we likely need to renovate the way we
      desugar infix type operators to be more consistent with the treatment
      for infix expressions (see
      https://ghc.haskell.org/trac/ghc/ticket/15815#comment:5 for more on
      this.) Doing so would constitute a breaking change, however, so we
      will likely want to wait until another major GHC release to do this.
      
      In the meantime, this patch offers a non-invasive change to the way
      that infix uses of `~` are desugared. This makes the program
      in #15815 compile again by inserting extra `HsParTy`s around the
      arguments to `~` if they are lacking them.
      
      Test Plan: make test TEST=T15815
      
      Reviewers: int-index, goldfire, bgamari
      
      Reviewed By: int-index
      
      Subscribers: int-e, rwbarton, carter
      
      GHC Trac Issues: #15815
      
      Differential Revision: https://phabricator.haskell.org/D5274
      b8a797ec
    • Ryan Scott's avatar
      Bump template-haskell version to 2.15.0.0 · e8a652f6
      Ryan Scott authored
      Summary:
      Commit 512eeb9b
      (`More explicit foralls (GHC Proposal 0007)`) introduced breaking
      changes to the Template Haskell AST. As a consequence of this, there
      are libraries in the wild that now fail to build on GHC HEAD (for
      instance, `th-abstraction`).
      
      This properly bumps the `template-haskell` library's version number
      to `2.15.0.0` so that these libraries can guard against these changes
      using `MIN_VERSION_template_haskell`.
      
      Test Plan: ./validate
      
      Reviewers: bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15818
      
      Differential Revision: https://phabricator.haskell.org/D5272
      e8a652f6
  27. 27 Oct, 2018 1 commit
    • mayac's avatar
      More explicit foralls (GHC Proposal 0007) · 512eeb9b
      mayac authored
      Allow the user to explicitly bind type/kind variables in type and data
      family instances (including associated instances), closed type family
      equations, and RULES pragmas. Follows the specification of GHC
      Proposal 0007, also fixes #2600. Advised by Richard Eisenberg.
      
      This modifies the Template Haskell AST -- old code may break!
      
      Other Changes:
      - convert HsRule to a record
      - make rnHsSigWcType more general
      - add repMaybe to DsMeta
      
      Includes submodule update for Haddock.
      
      Test Plan: validate
      
      Reviewers: goldfire, bgamari, alanz
      
      Subscribers: simonpj, RyanGlScott, goldfire, rwbarton,
                   thomie, mpickering, carter
      
      GHC Trac Issues: #2600, #14268
      
      Differential Revision: https://phabricator.haskell.org/D4894
      512eeb9b
  28. 24 Oct, 2018 3 commits
    • Simon Peyton Jones's avatar
      Improve output from -ddump-types · 321bc1a6
      Simon Peyton Jones authored
      This patch makes a number of improvements to the output
      generated by -ddump-types
      
      * Prints data constructor separately
      * Omits empty chunks of output
      
      I was driven initially by the unhelpful existing output for
      data constructors, but ended up doing some refactoring.
      
      Lots of error message wibbles, but nothing significant.
      Certainly no change in user behaviour.
      
      (NB: It is just possible that I have failed to cleanly
           separate this patch from the next one, about
           isPredTy and friends.)
      321bc1a6
    • Ryan Scott's avatar
      Fix #15792 by not reifying invisible arguments in AppTys · bfd93f90
      Ryan Scott authored
      Summary:
      The `reifyType` function in `TcSplice` is carefully designed
      to avoid reifying visible arguments to `TyConApp`s. However, the same
      care was not given towards the `AppTy` case, which lead to #15792.
      
      This patch changes to the `AppTy` case of `reifyType` so that it
      consults the kind of the function type to determine which of the
      argument types are invisible (and therefore should be dropped) during
      reification. This required crafting a variant of `tyConArgFlags`,
      which I dubbed `appTyArgFlags`, that accept an arbitrary function
      `Type` instead of a `TyCon`.
      
      Test Plan: make test TEST=T15792
      
      Reviewers: goldfire, bgamari, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: simonpj, rwbarton, carter
      
      GHC Trac Issues: #15792
      
      Differential Revision: https://phabricator.haskell.org/D5252
      bfd93f90
    • Ryan Scott's avatar
      Keep top-level names in typed TH quotes alive · bb835c96
      Ryan Scott authored
      Summary:
      When renaming untyped TH quotes, some care is taken to
      ensure that uses of top-level names in quotes do not have their
      bindings discarded during desugaring. The same care was not applied
      to typed TH quotes, so this patch brings the two into sync.
      
      Test Plan: make test TEST=T15783
      
      Reviewers: bgamari, mpickering
      
      Reviewed By: mpickering
      
      Subscribers: mpickering, rwbarton, carter
      
      GHC Trac Issues: #15783
      
      Differential Revision: https://phabricator.haskell.org/D5248
      bb835c96
  29. 15 Oct, 2018 2 commits
    • Vladislav Zavialov's avatar
      Enable -Wcompat=error in the testsuite · 165d3d5d
      Vladislav Zavialov authored
      Enabling -Werror=compat in the testsuite allows us to easily see the
      impact that a new warning has on code. It also means that in the period
      between adding the warning and making the actual breaking change, all
      new test cases that are being added to the testsuite will be
      forwards-compatible. This is good because it will make the actual
      breaking change contain less irrelevant testsuite updates.
      
      Things that -Wcompat warns about are things that are going to break in
      the future, so we can be proactive and keep our testsuite
      forwards-compatible.
      
      This patch consists of two main changes:
      
      * Add `TEST_HC_OPTS += -Werror=compat` to the testsuite configuration.
      * Fix all broken test cases.
      
      Test Plan: Validate
      
      Reviewers: hvr, goldfire, bgamari, simonpj, RyanGlScott
      
      Reviewed By: goldfire, RyanGlScott
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15278
      
      Differential Revision: https://phabricator.haskell.org/D5200
      165d3d5d
    • Ryan Scott's avatar
      Fix #15738 by defining (and using) parenthesizeHsContext · 02b2116e
      Ryan Scott authored
      With `QuantifiedConstraints`, `forall`s can appear in more
      nested positions than they could before, but `Convert` and the TH
      pretty-printer were failing to take this into account. On the
      `Convert` side, this is fixed by using a `parenthesizeHsContext`
      to parenthesize singleton quantified constraints that appear to the
      left of a `=>`. (A similar fix is applied to the TH pretty-printer.)
      
      Test Plan: make test TEST=T15738
      
      Reviewers: goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15738
      
      Differential Revision: https://phabricator.haskell.org/D5222
      02b2116e
  30. 04 Oct, 2018 3 commits
    • Alec Theriault's avatar
      Set `infixr -1 ->` · 251e3424
      Alec Theriault authored
      Summary:
      This simply makes explicit what is already the case. Due to special
      treatment in the parser, `->` has the lowest fixity. This patch propagates
      that information to:
      
        * GHCi, where `:info ->` now return the right fixity
        * TH, where `reifyFixity` returns the right fixity
        * the generated sources for `GHC.Prim`
      
      See #15235.
      
      Test Plan: make test
      
      Reviewers: bgamari, alanz, RyanGlScott
      
      Reviewed By: RyanGlScott
      
      Subscribers: int-index, RyanGlScott, rwbarton, mpickering, carter
      
      GHC Trac Issues: #15235
      
      Differential Revision: https://phabricator.haskell.org/D5199
      251e3424
    • Alec Theriault's avatar
      Don't drop arguments in TH type arguments · ba163c3b
      Alec Theriault authored
      Summary:
      When converting from TH AST back to HsType, we were occasionally
      dropping type arguments. This resulted in incorrectly accepted programs
      as well as incorrectly rejected programs.
      
      Test Plan: make TEST=T15360a && make TEST=T15360b
      
      Reviewers: goldfire, bgamari, tdammers
      
      Reviewed By: bgamari, tdammers
      
      Subscribers: RyanGlScott, rwbarton, carter
      
      GHC Trac Issues: #15360
      
      Differential Revision: https://phabricator.haskell.org/D5188
      ba163c3b
    • Simon Peyton Jones's avatar
      Better -ddump-types · e9e66402
      Simon Peyton Jones authored
      The debug flag -ddump-types is supposed to show the type
      of Ids, and the kinds of type constructors.  It was doing
      the former but not the latter -- instead it was using
      showTyTying, which is actually less helpful when debugging.
      
      This patch changes it to print the kind and roles of the thing.
      
      I also made -ddump-types show pattern synonyms
      e9e66402
  31. 27 Sep, 2018 1 commit
    • Simon Marlow's avatar
      Fix for recover with -fexternal-interpreter (#15418) · d00c3086
      Simon Marlow authored
      Summary:
      When using -fexternal-interpreter, recover was not treating a Q
      compuation that simply registered an error with addErrTc as failing.
      
      Test Plan:
      New unit tests:
      * T15418 is the repro from in the ticket
      * TH_recover_warns is a new test to ensure that we're keeping warnings when
        the body of recover succeeds.
      
      Reviewers: bgamari, RyanGlScott, angerman, goldfire, erikd
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15418
      
      Differential Revision: https://phabricator.haskell.org/D5185
      d00c3086
  32. 14 Sep, 2018 1 commit
    • Krzysztof Gogolewski's avatar
      Fix T15502 on 32-bit · ecbe26b6
      Krzysztof Gogolewski authored
      Summary:
      The expected output uses a hardcoded value for
      maxBound :: Int.
      
      This should fix one of circleci failures on i386.
      
      Test Plan: make test TEST=T15502
      
      Reviewers: RyanGlScott, bgamari
      
      Reviewed By: RyanGlScott
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15502
      
      Differential Revision: https://phabricator.haskell.org/D5151
      ecbe26b6