1. 02 Jan, 2018 3 commits
  2. 28 Dec, 2017 1 commit
  3. 26 Dec, 2017 2 commits
    • Richard Eisenberg's avatar
      Fix #14618 by applying a subst in deeplyInstantiate · 722a6584
      Richard Eisenberg authored
      Previously, we were inexplicably not applying an instantiating
      substitution to arguments in non-prenex types. It's amazing this
      has been around for so long! I guess there aren't a lot of non-prenex
      types around.
      
      test case: typecheck/should_fail/T14618
      722a6584
    • niteria's avatar
      Compute InScopeSet in substInteractiveContext · e19b6464
      niteria authored
      It doesn't look like we keep any sets of free variables
      of the types of Ids handy, so we just have to build them
      when doing a substitution.
      
      Test Plan: buildbot + run testsuite with debug
      
      Reviewers: simonmar, simonpj, austin, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: carter, rwbarton, thomie
      
      GHC Trac Issues: #11371
      
      Differential Revision: https://phabricator.haskell.org/D3431
      e19b6464
  4. 25 Dec, 2017 1 commit
  5. 23 Dec, 2017 1 commit
  6. 22 Dec, 2017 3 commits
  7. 21 Dec, 2017 12 commits
    • Herbert Valerio Riedel's avatar
      Sync `ghc-prim` changelog from GHC 8.2 · fc257e4b
      Herbert Valerio Riedel authored
      (cherry picked from commit 4d99a665)
      fc257e4b
    • Richard Eisenberg's avatar
      Comments only [skip ci] · 05551d00
      Richard Eisenberg authored
      This fixes a typo and elaborates the Note [TyVarBndrs ...]
      in TyCoRep, which was previously subtly wrong about
      Required ForAllTys.
      05551d00
    • Gabor Greif's avatar
      Typos in comments · bcb519c5
      Gabor Greif authored
      bcb519c5
    • Simon Peyton Jones's avatar
      Fix floating of equalities · f5cf9d1a
      Simon Peyton Jones authored
      This rather subtle patch fixes Trac #14584.  The problem was
      that we'd allowed a coercion, bound in a nested scope, to escape
      into an outer scope.
      
      The main changes are
      
      * TcSimplify.floatEqualities takes more care when floating
        equalities to make sure we don't float one out that mentions
        a locally-bound coercion.
        See Note [What prevents a constraint from floating]
      
      * TcSimplify.emitResidualConstraints (which emits the residual
        constraints in simplifyInfer) now avoids burying the constraints
        for escaping CoVars inside the implication constraint.
      
      * Since I had do to this stuff with CoVars, I moved the
        fancy footwork about not quantifying over CoVars from
        TcMType.quantifyTyVars to its caller
        TcSimplify.decideQuantifiedTyVars.  I think its other
        callers don't need to worry about all this CoVar stuff.
      
      This turned out to be surprisigly tricky, and took me a solid
      day to get right.  I think the result is reasonably neat, though,
      and well documented with Notes.
      f5cf9d1a
    • Simon Peyton Jones's avatar
      Refactor coercion holes · a492af06
      Simon Peyton Jones authored
      In fixing Trac #14584 I found that it would be /much/ more
      convenient if a "hole" in a coercion (much like a unification
      variable in a type) acutally had a CoVar associated with it
      rather than just a Unique.  Then I can ask what the free variables
      of a coercion is, and get a set of CoVars including those
      as-yet-un-filled in holes.
      
      Once that is done, it makes no sense to stuff coercion holes
      inside UnivCo.  They were there before so we could know the
      kind and role of a "hole" coercion, but once there is a CoVar
      we can get that info from the CoVar.  So I removed HoleProv
      from UnivCoProvenance and added HoleCo to Coercion.
      
      In summary:
      
      * Add HoleCo to Coercion and remove HoleProv from UnivCoProvanance
      
      * Similarly in IfaceCoercion
      
      * Make CoercionHole have a CoVar in it, not a Unique
      
      * Make tyCoVarsOfCo return the free coercion-hole variables
        as well as the ordinary free CoVars.  Similarly, remember
        to zonk the CoVar in a CoercionHole
      
      We could go further, and remove CoercionHole as a distinct type
      altogther, just collapsing it into HoleCo.  But I have not done
      that yet.
      a492af06
    • Simon Peyton Jones's avatar
      Check for bogus quantified tyvars in partial type sigs · 72938f58
      Simon Peyton Jones authored
      This fixes Trac #14479.  Not difficult.
      
      See Note [Quantification and partial signatures] Wrinkle 4,
      in TcSimplify.
      72938f58
    • Simon Peyton Jones's avatar
      Simplify HsPatSynDetails · 584cbd4a
      Simon Peyton Jones authored
      This is a pure refactoring.  Use HsConDetails to implement
      HsPatSynDetails, instead of defining a whole new data type.
      Less code, fewer types, all good.
      584cbd4a
    • Ryan Scott's avatar
      Improve treatment of sectioned holes · 4d41e921
      Ryan Scott authored
      Summary:
      Previously, GHC was pretty-printing left-section holes
      incorrectly and not parsing right-sectioned holes at all. This patch
      fixes both problems.
      
      Test Plan: make test TEST=T14590
      
      Reviewers: bgamari, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: simonpj, rwbarton, thomie, mpickering, carter
      
      GHC Trac Issues: #14590
      
      Differential Revision: https://phabricator.haskell.org/D4273
      4d41e921
    • Ryan Scott's avatar
      Document ScopedTypeVariables' interaction with nested foralls · b6304f8f
      Ryan Scott authored
      Summary:
      This documents the status quo with regards to how
      `ScopedTypeVariables` brings into scope type variables that are
      quantified by nested `forall`s (that is to say, it doesn't). This
      takes the prose in
      https://ghc.haskell.org/trac/ghc/ticket/14288#comment:5
      and enshrines it into the users' guide.
      
      Test Plan: Read it
      
      Reviewers: simonpj, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14288
      
      Differential Revision: https://phabricator.haskell.org/D4272
      b6304f8f
    • Ryan Scott's avatar
      Remove hack put in place for #12512 · 9cb289ab
      Ryan Scott authored
      Summary:
      Previously, I added an ad hoc check for unboxed tuples and
      sums in standalone-derived instances to fix #12512, under the
      pretense that polymorphism over `UnboxedTupleRep` and
      `UnboxedSumRep` was a lie. But that is no longer the case, and so
      this ad hoc check can be removed entirely. Less code, and easier to
      understand.
      
      Test Plan: make test TEST=T12512
      
      Reviewers: bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4271
      9cb289ab
    • 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
    • Ryan Scott's avatar
      Fix #14578 by checking isCompoundHsType in more places · 1bd91a7a
      Ryan Scott authored
      Summary:
      The `HsType` pretty-printer does not automatically insert
      parentheses where necessary for type applications, so a function
      `isCompoundHsType` was created in D4056 towards this purpose.
      However, it was not used in as many places as it ought to be,
      resulting in #14578.
      
      Test Plan: make test TEST=T14578
      
      Reviewers: alanz, bgamari, simonpj
      
      Reviewed By: alanz, simonpj
      
      Subscribers: simonpj, rwbarton, thomie, carter
      
      GHC Trac Issues: #14578
      
      Differential Revision: https://phabricator.haskell.org/D4266
      1bd91a7a
  8. 20 Dec, 2017 1 commit
  9. 19 Dec, 2017 3 commits
  10. 18 Dec, 2017 7 commits
  11. 15 Dec, 2017 2 commits
    • Richard Eisenberg's avatar
      Add some commentary re: fix to #11203 · 3910d3e2
      Richard Eisenberg authored
      The fix for #11203 prohibits duplicate SigTvs in non-CUSK kind
      signatures by checking for duplicates after type inference is
      done. This works well. GHC also checks for duplicate SigTvs
      after working with partial type signatures (another place where
      SigTvs arise). However, neither fix eliminates this whole class
      of problems (because doing so would be heavier than we would
      like). So, this comment adds a warning to users of newSigTyVar
      to be aware of problems with duplicates.
      3910d3e2
    • Simon Peyton Jones's avatar
      Fix tcDataKindSig · 68149452
      Simon Peyton Jones authored
      This patch fixes an outright bug in tcDataKindSig, shown up in Trac
      of a data type declaration.  See Note [TyConBinders for the result kind
      signature of a data type]
      
      I also took the opportunity to elminate the DataKindCheck argument
      and data type from tcDataKindSig, instead moving the check to the
      call site, which is easier to understand.
      68149452
  12. 14 Dec, 2017 4 commits