1. 27 Jul, 2018 1 commit
    • Simon Peyton Jones's avatar
      Refactor (~) to reduce the suerpclass stack · f265008f
      Simon Peyton Jones authored
      The constraint (~) used to be (effectively):
        class a ~~ b => (a :: k) ~ (b :: k)
      
      but, with this patch, it is now defined uniformly with
      (~~) and Coercible like this:
        class a ~# b => (a :: k) ~ (b :: k)
      
      Result:
        * One less superclass selection when goinng from (~) to (~#)
          Better for compile time and better for debugging with -ddump-simpl
      
        * The code for (~), (~~), and Coercible looks uniform, and appears
          together, e.g. in TysWiredIn and ClsInst.matchGlobalInst.
          Previously the code for (~) was different, and unique.
      
      Not only is this simpler, but it also makes the compiler a bit faster;
        T12227: 9% less allocation
        T12545: 7% less allocation
      
      This patch fixes Trac #15421
      f265008f
  2. 22 Jul, 2018 1 commit
  3. 16 Jul, 2018 1 commit
    • Vladislav Zavialov's avatar
      Do not imply NoStarIsType by TypeOperators/TypeInType · 65c186f0
      Vladislav Zavialov authored
      Implementation of the "Embrace TypeInType" proposal was done according
      to the spec, which specified that TypeOperators must imply NoStarIsType.
      This implication was meant to prevent breakage and to be removed in 2
      releases.  However, compiling head.hackage has shown that this
      implication only magnified the breakage, so there is no reason to have
      it in the first place.
      
      To remain in compliance with the three-release policy, we add a
      workaround to define the (*) type operator even when -XStarIsType is on.
      
      Test Plan: ./validate
      
      Reviewers: bgamari, RyanGlScott, goldfire, phadej, hvr
      
      Reviewed By: bgamari, RyanGlScott
      
      Subscribers: harpocrates, rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4865
      65c186f0
  4. 12 Jul, 2018 2 commits
  5. 06 Jul, 2018 1 commit
    • Michael Sloan's avatar
      Add a broken test for lingering state from TH unique names #9693 · fbe162f5
      Michael Sloan authored
      The stderr output is
      
      ```
      Loading with T9693_initial.hs
      
      T9693_main.hs:4:1:
          Same exact name in multiple name-spaces:
            type constructor or class ‘X’, declared at: T9693_main.hs:4:1
            data constructor ‘X’, declared at: T9693_main.hs:4:1
            Probable cause: you bound a unique Template Haskell name (NameU),
            perhaps via newName, in different name-spaces.
            If that's it, then -ddump-splices might be useful
      Reloading with T9693_modified.hs
      
      T9693_main.hs:1:1:
          Data constructor ‘X’ used as a type constructor
      ```
      
      The strange thing is that the modified version uses (mkName "X"), which should
      be fine for simultaneous use in both a data constructor and type constructor.
      Indeed, on a fresh load, the modified version works fine. So there is some sort
      of state left over from the prior load when (newName "X") was used.
      
      Test Plan: testsuite/tests/th/T9693.script
      
      Reviewers: bgamari, sighingnow, RyanGlScott
      
      Reviewed By: sighingnow, RyanGlScott
      
      Subscribers: RyanGlScott, sighingnow, rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4926
      fbe162f5
  6. 05 Jul, 2018 2 commits
  7. 04 Jul, 2018 1 commit
  8. 19 Jun, 2018 1 commit
  9. 15 Jun, 2018 1 commit
    • Sylvain Henry's avatar
      Built-in Natural literals in Core · fe770c21
      Sylvain Henry authored
      Add support for built-in Natural literals in Core.
      
      - Replace MachInt,MachWord, LitInteger, etc. with a single LitNumber
        constructor with a LitNumType field
      - Support built-in Natural literals
      - Add desugar warning for negative literals
      - Move Maybe(..) from GHC.Base to GHC.Maybe for module dependency
        reasons
      
      This patch introduces only a few rules for Natural literals (compared
      to Integer's rules). Factorization of the built-in rules for numeric
      literals will be done in another patch as this one is already big to
      review.
      
      Test Plan:
        validate
        test build with integer-simple
      
      Reviewers: hvr, bgamari, goldfire, Bodigrim, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: phadej, simonpj, RyanGlScott, carter, hsyl20, rwbarton,
      thomie
      
      GHC Trac Issues: #14170, #14465
      
      Differential Revision: https://phabricator.haskell.org/D4212
      fe770c21
  10. 14 Jun, 2018 1 commit
    • Vladislav Zavialov's avatar
      Embrace -XTypeInType, add -XStarIsType · d650729f
      Vladislav Zavialov authored
      Summary:
      Implement the "Embrace Type :: Type" GHC proposal,
      .../ghc-proposals/blob/master/proposals/0020-no-type-in-type.rst
      
      GHC 8.0 included a major change to GHC's type system: the Type :: Type
      axiom. Though casual users were protected from this by hiding its
      features behind the -XTypeInType extension, all programs written in GHC
      8+ have the axiom behind the scenes. In order to preserve backward
      compatibility, various legacy features were left unchanged. For example,
      with -XDataKinds but not -XTypeInType, GADTs could not be used in types.
      Now these restrictions are lifted and -XTypeInType becomes a redundant
      flag that will be eventually deprecated.
      
      * Incorporate the features currently in -XTypeInType into the
        -XPolyKinds and -XDataKinds extensions.
      * Introduce a new extension -XStarIsType to control how to parse * in
        code and whether to print it in error messages.
      
      Test Plan: Validate
      
      Reviewers: goldfire, hvr, bgamari, alanz, simonpj
      
      Reviewed By: goldfire, simonpj
      
      Subscribers: rwbarton, thomie, mpickering, carter
      
      GHC Trac Issues: #15195
      
      Differential Revision: https://phabricator.haskell.org/D4748
      d650729f
  11. 11 Jun, 2018 1 commit
  12. 10 Jun, 2018 1 commit
  13. 07 Jun, 2018 1 commit
  14. 30 May, 2018 1 commit
    • Matthías Páll Gissurarson's avatar
      Improved Valid Hole Fits · e0b44e2e
      Matthías Páll Gissurarson authored
      I've changed the name from `Valid substitutions` to `Valid hole fits`,
      since "substitution" already has a well defined meaning within the
      theory. As part of this change, the flags and output is reanamed, with
      substitution turning into hole-fit in most cases. "hole fit" was already
      used internally in the code, it's clear and shouldn't cause any
      confusion.
      
      In this update, I've also reworked how we manage side-effects in the
      hole we are considering.
      
      This allows us to consider local bindings such as where clauses and
      arguments to functions, suggesting e.g. `a` for `head (x:xs) where head
      :: [a] -> a`.
      
      It also allows us to find suggestions such as `maximum` for holes of
      type `Ord a => a -> [a]`, and `max` when looking for a match for the
      hole in `g = foldl1 _`, where `g :: Ord a => [a] -> a`.
      
      We also show much improved output for refinement hole fits, and
      fixes #14990. We now show the correct type of the function, but we also
      now show what the arguments to the function should be e.g. `foldl1 (_ ::
      Integer -> Integer -> Integer)` when looking for `[Integer] -> Integer`.
      
      I've moved the bulk of the code from `TcErrors.hs` to a new file,
      `TcHoleErrors.hs`, since it was getting too big to not live on it's own.
      
      This addresses the considerations raised in #14969, and takes proper
      care to set the `tcLevel` of the variables to the right level before
      passing it to the simplifier.
      
      We now also zonk the suggestions properly, which improves the output of
      the refinement hole fits considerably.
      
      This also filters out suggestions from the `GHC.Err` module, since even
      though `error` and `undefined` are indeed valid hole fits, they are
      "trivial", and almost never useful to the user.
      
      We now find the hole fits using the proper manner, namely by solving
      nested implications. This entails that the givens are passed along using
      the implications the hole was nested in, which in turn should mean that
      there will be fewer weird bugs in the typed holes.
      
      I've also added a new sorting method (as suggested by SPJ) and sort by
      the size of the types needed to turn the hole fits into the type of the
      hole. This gives a reasonable approximation to relevance, and is much
      faster than the subsumption check. I've also added a flag to toggle
      whether to use this new sorting algorithm (as is done by default) or the
      subsumption algorithm. This fixes #14969
      
      I've also added documentation for these new flags and update the
      documentation according to the new output.
      
      Reviewers: bgamari, goldfire
      
      Reviewed By: bgamari
      
      Subscribers: simonpj, rwbarton, thomie, carter
      
      GHC Trac Issues: #14969, #14990, #10946
      
      Differential Revision: https://phabricator.haskell.org/D4444
      e0b44e2e
  15. 24 May, 2018 1 commit
    • Ryan Scott's avatar
      Check for mismatched class methods during typechecking · 1879d9d2
      Ryan Scott authored
      Summary:
      Template Haskell provides a wormhole through which you can
      sneak methods that don't belong to a class into an instance for that
      class, bypassing the renamer's validity checks. The solution adopted
      here is to mirror the treatment for associated type family instances,
      which have an additional check in the typechecker which catch
      mismatched associated type families that were snuck through using
      Template Haskell. I've put a similar check for class methods into
      `tcMethods`.
      
      Test Plan: make test TEST=T12387
      
      Reviewers: bgamari, simonpj
      
      Reviewed By: bgamari, simonpj
      
      Subscribers: simonpj, rwbarton, thomie, carter
      
      GHC Trac Issues: #12387
      
      Differential Revision: https://phabricator.haskell.org/D4710
      1879d9d2
  16. 20 May, 2018 1 commit
  17. 14 May, 2018 1 commit
    • Ryan Scott's avatar
      Fix #14875 by introducing PprPrec, and using it · 21e1a00c
      Ryan Scott authored
      Trying to determine when to insert parentheses during TH
      conversion is a bit of a mess. There is an assortment of functions
      that try to detect this, such as:
      
      * `hsExprNeedsParens`
      * `isCompoundHsType`
      * `hsPatNeedsParens`
      * `isCompoundPat`
      * etc.
      
      To make things worse, each of them have slightly different semantics.
      Plus, they don't work well in the presence of explicit type
      signatures, as #14875 demonstrates.
      
      All of these problems can be alleviated with the use of an explicit
      precedence argument (much like what `showsPrec` currently does). To
      accomplish this, I introduce a new `PprPrec` data type, and define
      standard predences for things like function application, infix
      operators, function arrows, and explicit type signatures (that last
      one is new). I then added `PprPrec` arguments to the various
      `-NeedsParens` functions, and use them to make smarter decisions
      about when things need to be parenthesized.
      
      A nice side effect is that functions like `isCompoundHsType` are
      now completely unneeded, since they're simply aliases for
      `hsTypeNeedsParens appPrec`. As a result, I did a bit of refactoring
      to remove these sorts of functions. I also did a pass over various
      utility functions in GHC for constructing AST forms and used more
      appropriate precedences where convenient.
      
      Along the way, I also ripped out the existing `TyPrec`
      data type (which was tailor-made for pretty-printing `Type`s) and
      replaced it with `PprPrec` for consistency.
      
      Test Plan: make test TEST=T14875
      
      Reviewers: alanz, goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14875
      
      Differential Revision: https://phabricator.haskell.org/D4688
      21e1a00c
  18. 05 May, 2018 1 commit
    • Sebastian Graf's avatar
      Add 'addWordC#' PrimOp · 6243bba7
      Sebastian Graf authored
      This is mostly for congruence with 'subWordC#' and '{add,sub}IntC#'.
      I found 'plusWord2#' while implementing this, which both lacks
      documentation and has a slightly different specification than
      'addWordC#', which means the generic implementation is unnecessarily
      complex.
      
      While I was at it, I also added lacking meta-information on PrimOps
      and refactored 'subWordC#'s generic implementation to be branchless.
      
      Reviewers: bgamari, simonmar, jrtc27, dfeuer
      
      Reviewed By: bgamari, dfeuer
      
      Subscribers: dfeuer, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4592
      6243bba7
  19. 19 Apr, 2018 1 commit
  20. 10 Apr, 2018 1 commit
  21. 09 Apr, 2018 1 commit
    • Ryan Scott's avatar
      Bump template-haskell to 2.14.0.0 · 48f55e76
      Ryan Scott authored
      Summary:
      There has been at least one breaking change to
      `template-haskell` (the removal of `qAddForeignFile`) which is
      causing packages like `th-orphans` and `singletons` to fail to build
      with GHC HEAD. Let's bump `template-haskell`'s major version number
      so that these packages can properly guard against these changes.
      
      While I was in town, I also started a `changelog` section for
      the next major version of `template-haskell`, and copied over
      finishing touches for `template-haskell-2.13.0.0`.
      
      Test Plan: ./validate
      
      Reviewers: bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4558
      48f55e76
  22. 01 Apr, 2018 1 commit
    • Richard Eisenberg's avatar
      Track type variable scope more carefully. · faec8d35
      Richard Eisenberg authored
      The main job of this commit is to track more accurately the scope
      of tyvars introduced by user-written foralls. For example, it would
      be to have something like this:
      
        forall a. Int -> (forall k (b :: k). Proxy '[a, b]) -> Bool
      
      In that type, a's kind must be k, but k isn't in scope. We had a
      terrible way of doing this before (not worth repeating or describing
      here, but see the old tcImplicitTKBndrs and friends), but now
      we have a principled approach: make an Implication when kind-checking
      a forall. Doing so then hooks into the existing machinery for
      preventing skolem-escape, performing floating, etc. This also means
      that we bump the TcLevel whenever going into a forall.
      
      The new behavior is done in TcHsType.scopeTyVars, but see also
      TcHsType.tc{Im,Ex}plicitTKBndrs, which have undergone significant
      rewriting. There are several Notes near there to guide you. Of
      particular interest there is that Implication constraints can now
      have skolems that are out of order; this situation is reported in
      TcErrors.
      
      A major consequence of this is a slightly tweaked process for type-
      checking type declarations. The new Note [Use SigTvs in kind-checking
      pass] in TcTyClsDecls lays it out.
      
      The error message for dependent/should_fail/TypeSkolEscape has become
      noticeably worse. However, this is because the code in TcErrors goes to
      some length to preserve pre-8.0 error messages for kind errors. It's time
      to rip off that plaster and get rid of much of the kind-error-specific
      error messages. I tried this, and doing so led to a lovely error message
      for TypeSkolEscape. So: I'm accepting the error message quality regression
      for now, but will open up a new ticket to fix it, along with a larger
      error-message improvement I've been pondering. This applies also to
      dependent/should_fail/{BadTelescope2,T14066,T14066e}, polykinds/T11142.
      
      Other minor changes:
       - isUnliftedTypeKind didn't look for tuples and sums. It does now.
      
       - check_type used check_arg_type on both sides of an AppTy. But the left
         side of an AppTy isn't an arg, and this was causing a bad error message.
         I've changed it to use check_type on the left-hand side.
      
       - Some refactoring around when we print (TYPE blah) in error messages.
         The changes decrease the times when we do so, to good effect.
         Of course, this is still all controlled by
         -fprint-explicit-runtime-reps
      
      Fixes #14066 #14749
      
      Test cases: dependent/should_compile/{T14066a,T14749},
                  dependent/should_fail/T14066{,c,d,e,f,g,h}
      faec8d35
  23. 25 Mar, 2018 2 commits
    • Tao He's avatar
      Fix scoped type variables in TH for several constructs · a3986d7f
      Tao He authored
      Namely class methods, default signatures and pattern synonyms.
      
      When scoped type variables occur inside class default methods,
      default signatures and pattern synonyms, avoid re-create explicit
      type variables when represent the type signatures.
      
      This patch should fix Trac#14885.
      Signed-off-by: Tao He's avatarHE, Tao <sighingnow@gmail.com>
      
      Test Plan: make test TEST="T14885a T14885b T14885c"
      
      Reviewers: goldfire, bgamari, simonpj, RyanGlScott
      
      Reviewed By: simonpj, RyanGlScott
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14885
      
      Differential Revision: https://phabricator.haskell.org/D4469
      a3986d7f
    • Alec Theriault's avatar
      Support adding objects from TH · ceb91477
      Alec Theriault authored
      The user facing TH interface changes are:
      
        * 'addForeignFile' is renamed to 'addForeignSource'
        * 'qAddForeignFile'/'addForeignFile' now expect 'FilePath's
        * 'RawObject' is now a constructor for 'ForeignSrcLang'
        * 'qAddTempFile'/'addTempFile' let you request a temporary file
          from the compiler.
      
      Test Plan: unsure about this, added a TH test
      
      Reviewers: goldfire, bgamari, angerman
      
      Reviewed By: bgamari, angerman
      
      Subscribers: hsyl20, mboes, carter, simonmar, bitonic, ljli, rwbarton, thomie
      
      GHC Trac Issues: #14298
      
      Differential Revision: https://phabricator.haskell.org/D4217
      ceb91477
  24. 21 Mar, 2018 1 commit
    • Ryan Scott's avatar
      Fix #14869 by being more mindful of Type vs. Constraint · 49ac3f0f
      Ryan Scott authored
      Summary:
      Before, we were using `isLiftedTypeKind` in `reifyType`
      before checking if a type was `Constraint`. But as it turns out,
      `isLiftedTypeKind` treats `Constraint` the same as `Type`, so every
      occurrence of `Constraint` would be reified as `Type`! To make things
      worse, the documentation for `isLiftedTypeKind` stated that it
      treats `Constraint` //differently// from `Type`, which simply isn't
      true.
      
      This revises the documentation for `isLiftedTypeKind` to reflect
      reality, and defers the `isLiftedTypeKind` check in `reifyType` so
      that it does not accidentally swallow `Constraint`.
      
      Test Plan: make test TEST=T14869
      
      Reviewers: goldfire, bgamari
      
      Reviewed By: goldfire
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14869
      
      Differential Revision: https://phabricator.haskell.org/D4474
      49ac3f0f
  25. 19 Mar, 2018 1 commit
    • Chaitanya Koparkar's avatar
      Turn a TH Name for built-in syntax into an unqualified RdrName · 9868f91f
      Chaitanya Koparkar authored
      Previously, the Renamer would turn any fully qualified Template Haskell
      name into a corresponding fully qualified `RdrName`. But this is not
      what we want for built-in syntax, as it produces unnecessarily qualified
      names (eg. GHC.Types.[], GHC.Tuple.(,) etc.).
      
      Test Plan: ./validate
      
      Reviewers: RyanGlScott, bgamari, goldfire
      
      Reviewed By: RyanGlScott, bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #13776
      
      Differential Revision: https://phabricator.haskell.org/D4506
      9868f91f
  26. 05 Mar, 2018 1 commit
    • Ryan Scott's avatar
      Fix #14888 by adding more special cases for ArrowT · 6ee831f2
      Ryan Scott authored
      Summary:
      There were previously some situations where `(->)` would
      not be desugared or reified as `ArrowT`, leading to various oddities
      such as those observed in #14888. We now uniformly treat `(->)` as
      `ArrowT` in Template Haskell–world by checking for any tycon that
      has the same name as `(->)`, and converting that to `ArrowT`.
      
      Test Plan: make test TEST=T14888
      
      Reviewers: goldfire, bgamari, simonpj
      
      Reviewed By: goldfire, simonpj
      
      Subscribers: simonpj, rwbarton, thomie, carter
      
      GHC Trac Issues: #14888
      
      Differential Revision: https://phabricator.haskell.org/D4466
      6ee831f2
  27. 02 Mar, 2018 3 commits
    • Ryan Scott's avatar
      Fix #14838 by marking TH-spliced code as FromSource · ffb2738f
      Ryan Scott authored
      Previously, any Template Haskell code that was spliced would
      be marked as `Generated`, which would completely suppress pattern-
      match coverage warnings for it, which several folks found confusing.
      Indeed, Template Haskell-spliced code is "source" code in some sense,
      as users specifically request that it be put into their program, so
      changing its designation to `FromSource` makes sense from that
      perspective.
      
      Test Plan: make test TEST=T14838
      
      Reviewers: goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14838
      
      Differential Revision: https://phabricator.haskell.org/D4440
      ffb2738f
    • Ryan Scott's avatar
      Permit conversion of partially applied PromotedTupleTs · 68357020
      Ryan Scott authored
      Summary:
      We were simply missing a case in `Convert` for when have a
      `PromotedTupleT` that wasn't fully saturated. Easily fixed.
      
      Test Plan: make test TEST=T14843
      
      Reviewers: goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14843
      
      Differential Revision: https://phabricator.haskell.org/D4442
      68357020
    • Ryan Scott's avatar
      Fix #14817 by not double-printing data family instance kind signatures · aef2b429
      Ryan Scott authored
      Within `pprDataFamInstDecl`, we were invoking `pprFamInstLHS` to
      pretty-print a data family instance header, and we were passing `Just` a
      kind signature to `pprFamInstLHS` to make it pretty-print the kind
      signature alongside it (this is a consequence of commit
      d1ef223c). But this is silly, because
      then invoke `pp_data_defn`, which //also// pretty-prints the kind
      signature, resulting in the kind signature being printed twice by
      mistake.
      
      This fix is simple—pass `Nothing` to `pprFamInstLHS` instead.
      
      Test Plan: make test TEST=T14817
      
      Reviewers: alanz, bgamari, mpickering
      
      Reviewed By: mpickering
      
      Subscribers: mpickering, rwbarton, thomie, carter
      
      GHC Trac Issues: #14817
      
      Differential Revision: https://phabricator.haskell.org/D4418
      aef2b429
  28. 18 Feb, 2018 1 commit
    • Ryan Scott's avatar
      Rename the types in a GADT constructor in toposorted order · 043466b9
      Ryan Scott authored
      Previously, we were extracting the free variables from a
      GADT constructor in an incorrect order, which caused the type
      variables for the constructor's type signature to end up in
      non-toposorted order. Thankfully, rearranging the order of types
      during renaming makes swift work of this bug.
      
      This fixes a regression introduced in commit
      fa29df02.
      For whatever reason, that commit also commented out a
      significant portion of the `T13123` test. This code appears
      to work, so I've opted to uncomment it.
      
      Test Plan: make test TEST=T14808
      
      Reviewers: simonpj, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14808
      
      Differential Revision: https://phabricator.haskell.org/D4413
      043466b9
  29. 26 Jan, 2018 1 commit
    • Matthías Páll Gissurarson's avatar
      Sort valid substitutions for typed holes by "relevance" · cbdea959
      Matthías Páll Gissurarson authored
      This is an initial attempt at tackling the issue of how to order the
      suggestions provided by the valid substitutions checker, by sorting
      them by creating a graph of how they subsume each other. We'd like to
      order them in such a manner that the most "relevant" suggestions are
      displayed first, so that the suggestion that the user might be looking
      for is displayed before more far-fetched suggestions (and thus also
      displayed when they'd otherwise be cut-off by the
      `-fmax-valid-substitutions` limit). The previous ordering was based on
      the order in which the elements appear in the list of imports, which I
      believe is less correlated with relevance than this ordering.
      
      A drawback of this approach is that, since we now want to sort the
      elements, we can no longer "bail out early" when we've hit the
      `-fmax-valid-substitutions` limit.
      
      Reviewers: bgamari, dfeuer
      
      Reviewed By: dfeuer
      
      Subscribers: dfeuer, rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4326
      cbdea959
  30. 18 Jan, 2018 2 commits
    • Ryan Scott's avatar
      Fix #14681 and #14682 with precision-aimed parentheses · 575c009d
      Ryan Scott authored
      It turns out that `Convert` was recklessly leaving off
      parentheses in two places:
      
      * Negative numeric literals
      * Patterns in lambda position
      
      This patch fixes it by adding three new functions, `isCompoundHsLit`,
      `isCompoundHsOverLit`, and `isCompoundPat`, and using them in the
      right places in `Convert`. While I was in town, I also sprinkled
      `isCompoundPat` among some `Pat`-constructing functions in `HsUtils`
      to help avoid the likelihood of this problem happening in other
      places. One of these places is in `TcGenDeriv`, and sprinkling
      `isCompountPat` there fixes #14682
      
      Test Plan: make test TEST="T14681 T14682"
      
      Reviewers: alanz, goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14681, #14682
      
      Differential Revision: https://phabricator.haskell.org/D4323
      575c009d
    • Matthías Páll Gissurarson's avatar
      Inform hole substitutions of typeclass constraints (fixes #14273). · 1e14fd3e
      Matthías Páll Gissurarson authored
      This implements SPJ's suggestion on the ticket (#14273). We find the
      relevant constraints (ones that whose free unification variables are all
      mentioned in the type of the hole), and then clone the free unification
      variables of the hole and the relevant constraints. We then add a
      subsumption constraints and run the simplifier, and then check whether
      all the constraints were solved.
      
      Reviewers: bgamari
      
      Reviewed By: bgamari
      
      Subscribers: RyanGlScott, rwbarton, thomie, carter
      
      GHC Trac Issues: #14273
      
      Differential Revision: https://phabricator.haskell.org/D4315
      1e14fd3e
  31. 15 Jan, 2018 1 commit
  32. 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
  33. 30 Oct, 2017 1 commit
  34. 16 Oct, 2017 1 commit