1. 19 Apr, 2018 1 commit
    • Ryan Scott's avatar
      Fix #14710 with more validity checks during renaming · 447d1264
      Ryan Scott authored
      Summary:
      #14710 revealed two unfortunate regressions related to kind
      polymorphism that had crept in in recent GHC releases:
      
      1. While GHC was able to catch illegal uses of kind polymorphism
         (i.e., if `PolyKinds` wasn't enabled) in limited situations, it
         wasn't able to catch kind polymorphism of the following form:
      
      ```lang=haskell
      f :: forall a. a -> a
      f x = const x g
        where
          g :: Proxy (x :: a)
          g = Proxy
      ```
      
      Note that the variable `a` is being used as a kind variable in the
      type signature of `g`, but GHC happily accepts it, even without
      the use of `PolyKinds`.
      
      2. If you have `PolyKinds` (but not `TypeInType`) enabled, then GHC
         incorrectly accepts the following definition:
      
      ```lang=haskell
      f :: forall k (a :: k). Proxy a
      f = Proxy
      ```
      
      Even though `k` is explicitly bound and then later used as a kind
      variable within the same telescope.
      
      This patch fixes these two bugs as follows:
      
      1. Whenever we rename any `HsTyVar`, we check if the following three
         criteria are met:
      
         (a) It's a type variable
         (b) It's used at the kind level
         (c) `PolyKinds` is not enabled
      
         If so, then we have found an illegal use of kind polymorphism, so
         throw an error.
      
         This check replaces the `checkBadKindBndrs` function, which could
         only catch illegal uses of kind polymorphism in very limited
         situations (when the bad kind variable happened to be implicitly
         quantified in the same type signature).
      
      2. In `extract_hs_tv_bndrs`, we must error if `TypeInType` is not
         enabled and either of the following criteria are met:
      
         (a) An explicitly bound type variable is used in kind position
             in the body of a `forall` type.
         (b) An explicitly bound type variable is used in kind position
             in the kind of a bound type variable in a `forall` type.
      
         `extract_hs_tv_bndrs` was checking (a), but not (b). Easily fixed.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, simonpj, bgamari, hvr
      
      Reviewed By: simonpj
      
      Subscribers: thomie, carter
      
      GHC Trac Issues: #14710
      
      Differential Revision: https://phabricator.haskell.org/D4554
      447d1264
  2. 16 Apr, 2018 1 commit
  3. 13 Apr, 2018 5 commits
    • Sylvain Henry's avatar
      Enhanced constant folding · fea04def
      Sylvain Henry authored
      Until now GHC only supported basic constant folding (lit op lit, expr op
      0, etc.).
      
      This patch uses laws of +/-/* (associativity, commutativity,
      distributivity) to support some constant folding into nested
      expressions.
      
      Examples of new transformations:
      
         - simple nesting: (10 + x) + 10 becomes 20 + x
         - deep nesting: 5 + x + (y + (z + (t + 5))) becomes 10 + (x + (y + (z + t)))
         - distribution: (5 + x) * 6 becomes 30 + 6*x
         - simple factorization: 5 + x + (x + (x + (x + 5))) becomes 10 + (4 *x)
         - siblings: (5 + 4*x) - (3*x + 2) becomes 3 + x
      
      Test Plan: validate
      
      Reviewers: simonpj, austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      GHC Trac Issues: #9136
      
      Differential Revision: https://phabricator.haskell.org/D2858
      fea04def
    • Andreas Klebinger's avatar
      Omit ways depending on rts flags for #12870 related tests. · 9e89092d
      Andreas Klebinger authored
      Some of these tests instruct the RTS to ignore all RTS flags being
      passed.  While this is intended it causes test failures for some ways
      like profiling which depend on passing RTS flags. So we skip these ways.
      
      Test Plan: testsuite/tests/rts/flags$ make slow
      
      Reviewers: bgamari, simonmar, alpmestan
      
      Reviewed By: alpmestan
      
      Subscribers: alpmestan, thomie, carter
      
      GHC Trac Issues: #12870
      
      Differential Revision: https://phabricator.haskell.org/D4585
      9e89092d
    • Ryan Scott's avatar
      Fix #9438 by converting a panic to an error message · 7613a812
      Ryan Scott authored
      Previously, GHC was quite eager to panic whenever it was fed
      an archive file when `DYNAMIC_GHC_PROGRAMS=YES`. This ought to be an
      explicit error message instead, so this patch accomplishes just that.
      
      Test Plan: make test TEST=T14708
      
      Reviewers: Phyx, hvr, bgamari
      
      Reviewed By: Phyx
      
      Subscribers: thomie, carter
      
      GHC Trac Issues: #9438, #14708, #15032
      
      Differential Revision: https://phabricator.haskell.org/D4589
      7613a812
    • Ryan Scott's avatar
      Bump version numbers: base-4.11.1.0, integer-gmp-1.0.2.0 · c4814ab6
      Ryan Scott authored
      This takes care of bumping the `base` and `integer-gmp`
      minor version numbers in anticipation of a GHC 8.4.2 release.
      
      While I was in town, I also filled in a `@since TODO` Haddock
      annotation for `powModSecInteger` in `integer-gmp` with
      `1.0.2.0`, and updated the changelog accordingly.
      
      Test Plan: ./validate
      
      Reviewers: hvr, goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie, carter
      
      GHC Trac Issues: #15025
      
      Differential Revision: https://phabricator.haskell.org/D4586
      c4814ab6
    • Alan Zimmerman's avatar
      TTG for HsBinds and Data instances Plan B · b1386942
      Alan Zimmerman authored
      Summary:
      - Add the balance of the TTG extensions for hsSyn/HsBinds
      
      - Move all the (now orphan) data instances into hsSyn/HsInstances and
      use TTG Data instances Plan B
      https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/Instances#PLANB
      
      Updates haddock submodule.
      
      Illustrative numbers
      
      Compiling HsInstances before using Plan B.
      
      Max residency ~ 5G
      <<ghc: 629,864,691,176 bytes, 5300 GCs,
             321075437/1087762592 avg/max bytes residency (23 samples),
             2953M in use, 0.000 INIT (0.000 elapsed),
             383.511 MUT (384.986 elapsed), 37.426 GC (37.444 elapsed) :ghc>>
      
      Using Plan B
      
      Max residency 1.1G
      
      <<ghc: 78,832,782,968 bytes, 2884 GCs,
             222140352/386470152 avg/max bytes residency (34 samples),
             1062M in use, 0.001 INIT (0.001 elapsed),
             56.612 MUT (62.917 elapsed), 32.974 GC (32.923 elapsed) :ghc>>
      
      Test Plan: ./validate
      
      Reviewers: shayan-najd, goldfire, bgamari
      
      Subscribers: goldfire, thomie, mpickering, carter
      
      Differential Revision: https://phabricator.haskell.org/D4581
      b1386942
  4. 11 Apr, 2018 1 commit
  5. 10 Apr, 2018 3 commits
  6. 09 Apr, 2018 2 commits
  7. 07 Apr, 2018 1 commit
    • Ryan Scott's avatar
      Fix #14238 by always pretty-printing visible tyvars · 718a0181
      Ryan Scott authored
      Summary:
      Before, GHC would never print visible tyvars in the absence
      of `-fprint-explicit-foralls`, which led to `:kind` displaying
      incorrect kinds in GHCi. The fix is simple—simply check beforehand
      if any of the type variable binders are required when deciding when
      to pretty-print them.
      
      Test Plan: make test TEST=T14238
      
      Reviewers: simonpj, goldfire, bgamari
      
      Subscribers: thomie, carter
      
      GHC Trac Issues: #14238
      
      Differential Revision: https://phabricator.haskell.org/D4564
      718a0181
  8. 06 Apr, 2018 1 commit
  9. 02 Apr, 2018 5 commits
    • Richard Eisenberg's avatar
      Fix #14991. · d8d4266b
      Richard Eisenberg authored
      It turns out that solveEqualities really does need to use simpl_top.
      I thought that solveWanteds would be enough, and no existing test
      case showed up the different. #14991 shows that we need simpl_top.
      Easy enough to fix.
      
      test case: dependent/should_compile/T14991
      d8d4266b
    • Richard Eisenberg's avatar
      Mark test as expected to pass. · ddf89557
      Richard Eisenberg authored
      This fixes the SplitWD "unexpected pass". This test was fixed
      by ef443820 and somehow fell
      through my validation cracks.
      ddf89557
    • Simon Peyton Jones's avatar
      SpecConstr: accommodate casts in value arguments · 5ab8094e
      Simon Peyton Jones authored
      This commit:
      
        commit fb050a33
        Author: Simon Peyton Jones <simonpj@microsoft.com>
        Date:   Thu Oct 12 11:00:19 2017 +0100
      
        Do not bind coercion variables in SpecConstr rules
      
      arranged to reject any SpecConstr call pattern that mentioned
      a coercion in the pattern.
      
      There was a good reason for that
      -- see Note [SpecConstr and casts] --
      but I didn't realise how important it was to accept patterns
      that mention casts in /terms/.  Trac #14936 showed this up.
      
      This patch just narrows the restriction to discard only
      the cases where the coercion is mentioned only in types.
      Fortunately that was pretty easy to do.
      5ab8094e
    • Simon Peyton Jones's avatar
      Allow unpacking of single-data-con GADTs · 9187d5fb
      Simon Peyton Jones authored
      Trac #14978 pointed out that single-constructor GADTs should be
      unpackable without trouble.
      
      Acutally I realise that even existentials should be unpackable
      too, but that's a bit more work, so it's not part of this patch.
      
      See Note [Unpacking GADTs and existentials] in MkId.
      9187d5fb
    • Richard Eisenberg's avatar
      Test #14884, #14969 · 07abff71
      Richard Eisenberg authored
      These were fixed by faec8d35
      
      test cases: typecheck/should_fail/T14884
                  ghci/scripts/T14969
      07abff71
  10. 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
  11. 31 Mar, 2018 1 commit
  12. 27 Mar, 2018 2 commits
  13. 26 Mar, 2018 4 commits
    • alexvieth's avatar
      Fix performance of flattener patch (#12919) · b47a6c3a
      alexvieth authored
      This patch, authored by alexvieth and reviewed at D4451,
      makes performance improvements by critically optimizing parts
      of the flattener.
      
      Summary:
      T3064, T5321FD, T5321Fun, T9872a, T9872b, T9872c all pass.
      T9872a and T9872c show improvements beyond the -5% threshold.
      T9872d fails at 10.9% increased allocations.
      b47a6c3a
    • Richard Eisenberg's avatar
      Fix #12919 by making the flattener homegeneous. · e3dbb44f
      Richard Eisenberg authored
      This changes a key invariant of the flattener. Previously,
      flattening a type meant flattening its kind as well. But now,
      flattening is always homogeneous -- that is, the kind of the
      flattened type is the same as the kind of the input type.
      This is achieved by various wizardry in the TcFlatten.flatten_many
      function, as described in Note [flatten_many].
      
      There are several knock-on effects, including some refactoring
      in the canonicalizer to take proper advantage of the flattener's
      changed behavior. In particular, the tyvar case of can_eq_nc' no
      longer needs to take casts into account.
      
      Another effect is that flattening a tyconapp might change it
      into a casted tyconapp. This might happen if the result kind
      of the tycon contains a variable, and that variable changes
      during flattening. Because the flattener is homogeneous, it tacks
      on a cast to keep the tyconapp kind the same. However, this
      is problematic when flattening CFunEqCans, which need to have
      an uncasted tyconapp on the LHS and must remain homogeneous.
      The solution is a more involved canCFunEqCan, described in
      Note [canCFunEqCan].
      
      This patch fixes #13643 (as tested in typecheck/should_compile/T13643)
      and the panic in typecheck/should_compile/T13822 (as reported in #14024).
      Actually, there were two bugs in T13822: the first was just some
      incorrect logic in tryFill (part of the unflattener) -- also fixed
      in this patch -- and the other was the main bug fixed in this ticket.
      
      The changes in this patch exposed a long-standing flaw in OptCoercion,
      in that breaking apart an AppCo sometimes has unexpected effects on
      kinds. See new Note [EtaAppCo] in OptCoercion, which explains the
      problem and fix.
      
      Also here is a reversion of the major change in
      09bf135a, affecting ctEvCoercion.
      It turns out that making the flattener homogeneous changes the
      invariants on the algorithm, making the change in that patch
      no longer necessary.
      
      This patch also fixes:
        #14038 (dependent/should_compile/T14038)
        #13910 (dependent/should_compile/T13910)
        #13938 (dependent/should_compile/T13938)
        #14441 (typecheck/should_compile/T14441)
        #14556 (dependent/should_compile/T14556)
        #14720 (dependent/should_compile/T14720)
        #14749 (typecheck/should_compile/T14749)
      
      Sadly, this patch negatively affects performance of type-family-
      heavy code. The following patch fixes these performance degradations.
      However, the performance fixes are somewhat invasive and so I've
      kept them as a separate patch, labeling this one as [skip ci] so
      that validation doesn't fail on the performance cases.
      e3dbb44f
    • Reiner Pope's avatar
      Add unaligned bytearray access primops. Fixes #4442. · efd70cfb
      Reiner Pope authored
      Reviewers: bgamari, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: dfeuer, rwbarton, thomie, carter
      
      GHC Trac Issues: #4442
      
      Differential Revision: https://phabricator.haskell.org/D4488
      efd70cfb
    • Ben Gamari's avatar
      Add new debugging flag -dinline-check · ecfb4d36
      Ben Gamari authored
      This flag reports a summary of the inlining decision for identifiers
      prefixed by the flag's argument.
      
      For example, `-dinline-check foo` will report why definitions whose
      prefix is `foo` are inlined or not.
      
      Previously the only way to get this information was to pass a
      combination of `-dverbose-core2core` and `-ddump-inlinings`.
      
      This combination led to a log of 12 million lines in a module of about
      200 lines I recently had to apply it to. This flag provides a much more
      direct way to find the occurence you care about.
      
      Reviewers: osa1, dfeuer, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4458
      ecfb4d36
  14. 25 Mar, 2018 8 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
    • niteria's avatar
      Don't refer to blocks in debug info when -g1 · 0cbb13b3
      niteria authored
      -g1 removes block information, but it turns out that procs can
      refer to block information through parents.
      Note [Splitting DebugBlocks] explains the parentage relationship.
      
      Test Plan:
      * ./validate
      * added a new test
      
      Reviewers: bgamari, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14894
      
      Differential Revision: https://phabricator.haskell.org/D4496
      0cbb13b3
    • Ryan Scott's avatar
      Fix #14916 with an additional validity check in deriveTyData · 20f14b4f
      Ryan Scott authored
      Manually-written instances and standalone-derived instances
      have the benefit of having the `checkValidInstHead` function run over
      them, which catches manual instances of built-in types like `(~)` and
      `Coercible`. However, instances generated from `deriving` clauses
      weren't being passed through `checkValidInstHead`, leading to
      confusing results as in #14916.
      
      `checkValidInstHead` also has additional validity checks for language
      extensions like `FlexibleInstances` and `MultiParamTypeClasses`. Up
      until now, GHC has never required these language extensions for
      `deriving` clause, so to avoid unnecessary breakage, I opted to
      suppress these language extension checks for `deriving` clauses, just
      like we currently suppress them for `SPECIALIZE instance` pragmas.
      
      Test Plan: make test TEST=T14916
      
      Reviewers: goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14916
      
      Differential Revision: https://phabricator.haskell.org/D4501
      20f14b4f
    • Ben Gamari's avatar
      testsuite: Add test for #14925 · 0703c00f
      Ben Gamari authored
      Test Plan: Validate
      
      Reviewers: alpmestan
      
      Reviewed By: alpmestan
      
      Subscribers: alpmestan, leftaroundabout, rwbarton, thomie, carter
      
      GHC Trac Issues: #14925
      
      Differential Revision: https://phabricator.haskell.org/D4512
      0703c00f
    • Adam Gundry's avatar
      Fix panic on module re-exports of DuplicateRcordFields · fb462f94
      Adam Gundry authored
      Test Plan: new test overloadedrecflds/should_fail/T14953
      
      Reviewers: mpickering, simonpj, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14953
      
      Differential Revision: https://phabricator.haskell.org/D4527
      fb462f94
    • Ryan Scott's avatar
      Fix two pernicious bugs in DeriveAnyClass · 98930426
      Ryan Scott authored
      The way GHC was handling `DeriveAnyClass` was subtly wrong
      in two notable ways:
      
      * In `inferConstraintsDAC`, we were //always// bumping the `TcLevel`
        of newly created unification variables, under the assumption that
        we would always place those unification variables inside an
        implication constraint. But #14932 showed precisely the scenario
        where we had `DeriveAnyClass` //without// any of the generated
        constraints being used inside an implication, which made GHC
        incorrectly believe the unification variables were untouchable.
      * Even worse, we were using the generated unification variables from
        `inferConstraintsDAC` in every single iteration of `simplifyDeriv`.
        In #14933, however, we have a scenario where we fill in a
        unification variable with a skolem in one iteration, discard it,
        proceed on to another iteration, use the same unification variable
        (still filled in with the old skolem), and try to unify it with
        a //new// skolem! This results in an utter disaster.
      
      The root of both these problems is `inferConstraintsDAC`. This patch
      fixes the issue by no longer generating unification variables
      directly in `inferConstraintsDAC`. Instead, we store the original
      variables from a generic default type signature in `to_metas`, a new
      field of `ThetaOrigin`, and in each iteration of `simplifyDeriv`, we
      generate fresh meta tyvars (avoiding the second issue). Moreover,
      this allows us to more carefully fine-tune the `TcLevel` under which
      we create these meta tyvars, fixing the first issue.
      
      Test Plan: make test TEST="T14932 T14933"
      
      Reviewers: simonpj, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14932, #14933
      
      Differential Revision: https://phabricator.haskell.org/D4507
      98930426
    • Ben Gamari's avatar
      testsuite: Add test for #14931 · 7bb1fde1
      Ben Gamari authored
      Reviewers: alpmestan
      
      Reviewed By: alpmestan
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14931
      
      Differential Revision: https://phabricator.haskell.org/D4518
      7bb1fde1
    • 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
  15. 23 Mar, 2018 2 commits
    • Ryan Scott's avatar
      Allow PartialTypeSignatures in standalone deriving contexts · affdea82
      Ryan Scott authored
      Summary:
      At its core, this patch is a simple tweak that allows a user
      to write:
      
      ```lang=haskell
      deriving instance _ => Eq (Foo a)
      ```
      
      Which is functionally equivalent to:
      
      ```lang=haskell
      data Foo a = ...
        deriving Eq
      ```
      
      But with the added flexibility that `StandaloneDeriving` gives you
      (namely, the ability to use it anywhere, not just in the same module
      that `Foo` was declared in). This fixes #13324, and should hopefully
      address a use case brought up in #10607.
      
      Currently, only the use of a single, extra-constraints wildcard is
      permitted in a standalone deriving declaration. Any other wildcard
      is rejected, so things like
      `deriving instance (Eq a, _) => Eq (Foo a)` are currently forbidden.
      
      There are quite a few knock-on changes brought on by this change:
      
      * The `HsSyn` type used to represent standalone-derived instances
        was previously `LHsSigType`, which isn't sufficient to hold
        wildcard types. This needed to be changed to `LHsSigWcType` as a
        result.
      
      * Previously, `DerivContext` was a simple type synonym for
        `Maybe ThetaType`, under the assumption that you'd only ever be in
        the `Nothing` case if you were in a `deriving` clause. After this
        patch, that assumption no longer holds true, as you can also be
        in this situation with standalone deriving when an
        extra-constraints wildcard is used.
      
        As a result, I changed `DerivContext` to be a proper datatype that
        reflects the new wrinkle that this patch adds, and plumbed this
        through the relevant parts of `TcDeriv` and friends.
      
      * Relatedly, the error-reporting machinery in `TcErrors` also assumed
        that if you have any unsolved constraints in a derived instance,
        then you should be able to fix it by switching over to standalone
        deriving. This was always sound advice before, but with this new
        feature, it's possible to have unsolved constraints even when
        you're standalone-deriving something!
      
        To rectify this, I tweaked some constructors of `CtOrigin` a bit
        to reflect this new subtlety.
      
      This requires updating the Haddock submodule. See my fork at
      https://github.com/RyanGlScott/haddock/commit/067d52fd4be15a1842cbb05f42d9d482de0ad3a7
      
      Test Plan: ./validate
      
      Reviewers: simonpj, goldfire, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: goldfire, rwbarton, thomie, mpickering, carter
      
      GHC Trac Issues: #13324
      
      Differential Revision: https://phabricator.haskell.org/D4383
      affdea82
    • Ryan Scott's avatar
      Special-case record fields ending with hash when deriving Read · d5577f44
      Ryan Scott authored
      Summary:
      In commit dbd81f7e, a
      regression was inadvertently introduced which caused derived `Read`
      instances for record data types with fields ending in a `#` symbol
      (using `MagicHash`) would no longer parse on valid output. This
      is ultimately due to the same reasons as #5041, as we cannot parse
      a field name like `foo#` as a single identifier. We fix this issue
      by employing the same workaround as in #5041: first parse the
      identifier name `foo`, then then symbol `#`.
      
      This is accomplished by the new `readFieldHash` function in
      `GHC.Read`. This will likely warrant a `base-4.11.1.0` release.
      
      Test Plan: make test TEST=T14918
      
      Reviewers: tdammers, hvr, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14918
      
      Differential Revision: https://phabricator.haskell.org/D4502
      d5577f44
  16. 22 Mar, 2018 1 commit
  17. 21 Mar, 2018 1 commit