1. 27 Jan, 2016 2 commits
  2. 26 Jan, 2016 4 commits
    • niteria's avatar
      Construct in_scope set in mkTopTCvSubst · 144ddb41
      niteria authored
      The pre-condition on `mkTopTCvSubst` turned out to be wrong and
      not satisfied by any of the callers. I've fixed it, so that it
      constructs the in_scope set from the range of the substitution.
      `mkTopTCvSubst` was also unnecessarily general it is never called
      with `CoVars`, so I changed the type signature and added an assertion.
      
      Test Plan: ./validate --slow
      
      Reviewers: goldfire, simonpj, bgamari, austin
      
      Reviewed By: simonpj
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1801
      
      GHC Trac Issues: #11371
      144ddb41
    • niteria's avatar
      Pass InScopeSet to substTy in lintTyApp · 01809bcd
      niteria authored
      This is the fix proposed in #11371:
      ```
      In other cases, we already have the in-scope set in hand. Example: in
      CoreLint.lintTyApp we find a call to substTyWith. But Lint carries an
      in-scope set, so it would be easy to pass it to substTyWith.
      ```
      
      Test Plan: ./validate --slow (only pre-existing problems)
      
      Reviewers: simonpj, goldfire, austin, nomeata, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1820
      
      GHC Trac Issues: #11371
      01809bcd
    • Simon Peyton Jones's avatar
      Fix two cloning-related bugs · 016a0bd1
      Simon Peyton Jones authored
      Crikey!  Not just one but two bugs in type variable cloning,
      both dating from the days before PolyKinds.  Both were shown up
      by Trac #11330.
      
      1. In SetLevels, when floating a case expression we must clone its
         binders, *and* do so in a telescope-aware way, because the
         constructor may bind a kind variable that appears in the kind
         of a type variable.
      
         Instead of doing this (wrongly) by steam, call CoreSubst.cloneBndrs.
      
         I added Notes and did other refactoring at the same time.
      
      2. It turned out that CoreSubst.cloneBndrs calls TyCoRep.cloneTyVarBndr,
         and that too was bogus!  It didn't substitute in the kind of the
         TyVar being cloned.  There was even a comment to say "variables can't
         appear in kinds".  Thta hasn't been true for a long time now.
      
      Easily fixed.
      
      Interestingly, I then found that test
         dependent/should_compile/KindEqualities
      was emitting a new inexhaustive-pattern-match warning.  Sure enough
      it was valid!  So the lack of cloning in cloneTyVarBndr really was
      causing an observable bug; just one that we had not observed.
      016a0bd1
    • Simon Peyton Jones's avatar
      Kill off zipTopTCvSubst in favour of zipOpenTCvSubst · 1c6d70c2
      Simon Peyton Jones authored
      As Bartosz has discovered, the invariants for substitutions were
      wrong, and in particular the "mkTop...Subst" and "zipTop..Subst"
      functions were building substitutions that didn't obey even the
      old invariants.
      
      This patch kills of the bogus zipTopTCvSubst in favour of the
      more robust zipOpenTCvSubst.
      
      I tripped over this because my upcoming patch (concerning SetLevels,
      Trac #11330) triggered an ASSERT failure in the substitution
      well-formedness assertion in TyCoRep.
      1c6d70c2
  3. 21 Jan, 2016 2 commits
    • Ben Gamari's avatar
      TyCoRep: Restore compatibility with 7.10.1 · ede055eb
      Ben Gamari authored
      Sadly CallStack wasn't present in 7.10.1, breaking the build when
      bootstrapping from this version.
      
      This patch essentially disables CallStack support for stage1 builds with
      7.10.*. This doesn't seem so unreasonable though as stage2 will still
      work.
      
      Test Plan: Validate with 7.10.1
      
      Reviewers: gridaphobe, jstolarek, austin
      
      Reviewed By: jstolarek
      
      Subscribers: thomie, jstolarek
      
      Differential Revision: https://phabricator.haskell.org/D1812
      
      GHC Trac Issues: #11472
      ede055eb
    • Simon Peyton Jones's avatar
      Add comments about tyCoVarsOfType · 2e65aae7
      Simon Peyton Jones authored
      See Note [Free variables of types].
      
      Richard to check.
      2e65aae7
  4. 19 Jan, 2016 1 commit
    • niteria's avatar
      Check InScopeSet in substTy and provide substTyUnchecked · 9d33adb6
      niteria authored
      This adds sanity checks to `substTy` that implement:
      
      > when calling substTy subst ty it should be the case that the in-scope
      > set in the substitution is a superset of
      > * The free vars of the range of the substitution
      > * The free vars of ty minus the domain of the substitution
      
      and replaces violators with unchecked version. The violators were found
      by running the GHC test suite.
      
      This ensures that I can work on this incrementally and that what I fix won't
      be undone by some other change.
      
      It also includes a couple of fixes that I've already done.
      
      Test Plan: ./validate
      
      Reviewers: simonmar, goldfire, simonpj, austin, bgamari
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1792
      
      GHC Trac Issues: #11371
      9d33adb6
  5. 18 Jan, 2016 2 commits
    • Jan Stolarek's avatar
      Replace calls to `ptext . sLit` with `text` · b8abd852
      Jan Stolarek authored
      Summary:
      In the past the canonical way for constructing an SDoc string literal was the
      composition `ptext . sLit`.  But for some time now we have function `text` that
      does the same.  Plus it has some rules that optimize its runtime behaviour.
      This patch takes all uses of `ptext . sLit` in the compiler and replaces them
      with calls to `text`.  The main benefits of this patch are clener (shorter) code
      and less dependencies between module, because many modules now do not need to
      import `FastString`.  I don't expect any performance benefits - we mostly use
      SDocs to report errors and it seems there is little to be gained here.
      
      Test Plan: ./validate
      
      Reviewers: bgamari, austin, goldfire, hvr, alanz
      
      Subscribers: goldfire, thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D1784
      b8abd852
    • Eric Seidel's avatar
      un-wire-in error, undefined, CallStack, and IP · a7b751db
      Eric Seidel authored
      I missed a crucial step in the wiring-in process of `CallStack` in D861,
      the bit where you actually wire-in the Name... This led to a nasty bug
      where GHC thought `CallStack` was not wired-in and tried to fingerprint
      it, which failed because the defining module was not loaded.
      
      But we don't need `CallStack` to be wired-in anymore since `error` and
      `undefined` no longer need to be wired-in. So we just remove them all.
      
      Updates haddock submodule.
      
      Test Plan: `./validate` and `make slowtest TEST=tc198`
      
      Reviewers: simonpj, goldfire, austin, hvr, bgamari
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: goldfire, thomie
      
      Projects: #ghc
      
      Differential Revision: https://phabricator.haskell.org/D1739
      
      GHC Trac Issues: #11331
      a7b751db
  6. 26 Dec, 2015 1 commit
  7. 24 Dec, 2015 2 commits
    • eir@cis.upenn.edu's avatar
      Visible type application · 2db18b81
      eir@cis.upenn.edu authored
      This re-working of the typechecker algorithm is based on
      the paper "Visible type application", by Richard Eisenberg,
      Stephanie Weirich, and Hamidhasan Ahmed, to be published at
      ESOP'16.
      
      This patch introduces -XTypeApplications, which allows users
      to say, for example `id @Int`, which has type `Int -> Int`. See
      the changes to the user manual for details.
      
      This patch addresses tickets #10619, #5296, #10589.
      2db18b81
    • Simon Peyton Jones's avatar
      Refactoring only · 1af0d36b
      Simon Peyton Jones authored
      This moves code around to more sensible places.
      
      - Construction for CoAxiom is localised in FamInstEnv
      
      - orphNamesOfxx moves to CoreFVs
      
      - roughMatchTcs, instanceCantMatch moves to Unify
      
      - mkNewTypeCo moves from Coercion to FamInstEnv, and is
        renamed mkNewTypeCoAxiom, which makes more sense
      1af0d36b
  8. 22 Dec, 2015 4 commits
    • eir@cis.upenn.edu's avatar
      CoercionN is not in scope in TyCoRep · 21b25dff
      eir@cis.upenn.edu authored
      21b25dff
    • eir@cis.upenn.edu's avatar
      Tweak comments around UnivCos. · d3ce4172
      eir@cis.upenn.edu authored
      d3ce4172
    • Simon Peyton Jones's avatar
      Fix typechecking for pattern synonym signatures · f40e122b
      Simon Peyton Jones authored
      Various tickets have revealed bad shortcomings in the typechecking of
      pattern type synonyms.  Discussed a lot in (the latter part of)
      Trac #11224.
      
      This patch fixes the most complex issues:
      
      - Both parser and renamer now treat pattern synonyms as an
        ordinary LHsSigType.  Nothing special.  Hooray.
      
      - tcPatSynSig (now in TcPatSyn) typechecks the signature, and
        decomposes it into its pieces.
        See Note [Pattern synonym signatures]
      
      - tcCheckPatSyn has had a lot of refactoring.
        See Note [Checking against a pattern signature]
      
      The result is a lot tidier and more comprehensible.
      Plus, it actually works!
      
      NB: this patch doesn't actually address the precise
          target of #11224, namely "inlining pattern synonym
          does not preserve semantics".  That's an unrelated
          bug, with a separate patch.
      
      ToDo: better documentation in the user manual
      
      Test Plan: Validate
      
      Reviewers: austin, hvr, goldfire
      
      Subscribers: goldfire, mpickering, thomie, simonpj
      
      Differential Revision: https://phabricator.haskell.org/D1685
      
      GHC Trac Issues: #11224
      f40e122b
    • Simon Peyton Jones's avatar
      Comments only, about coercion holes · ea3f733a
      Simon Peyton Jones authored
      Richard, pls take a look
      ea3f733a
  9. 16 Dec, 2015 1 commit
  10. 11 Dec, 2015 1 commit
    • eir@cis.upenn.edu's avatar
      Add kind equalities to GHC. · 67465497
      eir@cis.upenn.edu authored
      This implements the ideas originally put forward in
      "System FC with Explicit Kind Equality" (ICFP'13).
      
      There are several noteworthy changes with this patch:
       * We now have casts in types. These change the kind
         of a type. See new constructor `CastTy`.
      
       * All types and all constructors can be promoted.
         This includes GADT constructors. GADT pattern matches
         take place in type family equations. In Core,
         types can now be applied to coercions via the
         `CoercionTy` constructor.
      
       * Coercions can now be heterogeneous, relating types
         of different kinds. A coercion proving `t1 :: k1 ~ t2 :: k2`
         proves both that `t1` and `t2` are the same and also that
         `k1` and `k2` are the same.
      
       * The `Coercion` type has been significantly enhanced.
         The documentation in `docs/core-spec/core-spec.pdf` reflects
         the new reality.
      
       * The type of `*` is now `*`. No more `BOX`.
      
       * Users can write explicit kind variables in their code,
         anywhere they can write type variables. For backward compatibility,
         automatic inference of kind-variable binding is still permitted.
      
       * The new extension `TypeInType` turns on the new user-facing
         features.
      
       * Type families and synonyms are now promoted to kinds. This causes
         trouble with parsing `*`, leading to the somewhat awkward new
         `HsAppsTy` constructor for `HsType`. This is dispatched with in
         the renamer, where the kind `*` can be told apart from a
         type-level multiplication operator. Without `-XTypeInType` the
         old behavior persists. With `-XTypeInType`, you need to import
         `Data.Kind` to get `*`, also known as `Type`.
      
       * The kind-checking algorithms in TcHsType have been significantly
         rewritten to allow for enhanced kinds.
      
       * The new features are still quite experimental and may be in flux.
      
       * TODO: Several open tickets: #11195, #11196, #11197, #11198, #11203.
      
       * TODO: Update user manual.
      
      Tickets addressed: #9017, #9173, #7961, #10524, #8566, #11142.
      Updates Haddock submodule.
      67465497