This project is mirrored from https://gitlab.haskell.org/ghc/ghc.git. Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer.
Last successful update .
  1. 24 Oct, 2016 2 commits
  2. 23 Sep, 2016 1 commit
    • Richard Eisenberg's avatar
      Fix #12442. · 9766b0c8
      Richard Eisenberg authored
      The problem is described in the ticket.
      
      This patch adds new variants of the access points to the pure
      unifier that allow unification of types only when the caller
      wants this behavior. (The unifier used to also unify kinds.)
      This behavior is appropriate when the kinds are either already
      known to be the same, or the list of types provided are a
      list of well-typed arguments to some type constructor. In the
      latter case, unifying earlier types in the list will unify the
      kinds of any later (dependent) types.
      
      At use sites, I went through and chose the unification function
      according to the criteria above.
      
      This patch includes some modest performance improvements as we
      are now doing less work.
      9766b0c8
  3. 28 Jun, 2016 1 commit
    • Simon Peyton Jones's avatar
      Wibble error message for #11471 · dc62a222
      Simon Peyton Jones authored
      I'm not quite sure why this changed with my two recent commits,
      but it /has/ changed (in a benign way) so I'm accepting it.
      Maybe it wasn't me anyway... but life is short and I'm not inclined
      to dig further.
      dc62a222
  4. 22 Jun, 2016 1 commit
  5. 20 Jun, 2016 1 commit
  6. 15 Jun, 2016 1 commit
    • Simon Peyton Jones's avatar
      Re-add FunTy (big patch) · 77bb0927
      Simon Peyton Jones authored
      With TypeInType Richard combined ForAllTy and FunTy, but that was often
      awkward, and yielded little benefit becuase in practice the two were
      always treated separately.  This patch re-introduces FunTy.  Specfically
      
      * New type
          data TyVarBinder = TvBndr TyVar VisibilityFlag
        This /always/ has a TyVar it.  In many places that's just what
        what we want, so there are /lots/ of TyBinder -> TyVarBinder changes
      
      * TyBinder still exists:
          data TyBinder = Named TyVarBinder | Anon Type
      
      * data Type = ForAllTy TyVarBinder Type
                  | FunTy Type Type
                  |  ....
      
      There are a LOT of knock-on changes, but they are all routine.
      
      The Haddock submodule needs to be updated too
      77bb0927
  7. 13 Jun, 2016 1 commit
    • Simon Peyton Jones's avatar
      Improve typechecking of let-bindings · 15b9bf4b
      Simon Peyton Jones authored
      This major commit was initially triggered by #11339, but it spiraled
      into a major review of the way in which type signatures for bindings
      are handled, especially partial type signatures.  On the way I fixed a
      number of other bugs, namely
         #12069
         #12033
         #11700
         #11339
         #11670
      
      The main change is that I completely reorganised the way in which type
      signatures in bindings are handled. The new story is in TcSigs
      Note [Overview of type signatures].  Some specific:
      
      * Changes in the data types for signatures in TcRnTypes:
        TcIdSigInfo and new TcIdSigInst
      
      * New module TcSigs deals with typechecking type signatures
        and pragmas. It contains code mostly moved from TcBinds,
        which is already too big
      
      * HsTypes: I swapped the nesting of HsWildCardBndrs
        and HsImplicitBndsrs, so that the wildcards are on the
        oustide not the insidde in a LHsSigWcType.  This is just
        a matter of convenient, nothing deep.
      
      There are a host of other changes as knock-on effects, and
      it all took FAR longer than I anticipated :-).  But it is
      a significant improvement, I think.
      
      Lots of error messages changed slightly, some just variants but
      some modest improvements.
      
      New tests
      
      * typecheck/should_compile
          * SigTyVars: a scoped-tyvar test
          * ExPat, ExPatFail: existential pattern bindings
          * T12069
          * T11700
          * T11339
      
      * partial-sigs/should_compile
          * T12033
          * T11339a
          * T11670
      
      One thing to check:
      
      * Small change to output from ghc-api/landmines.
        Need to check with Alan Zimmerman
      15b9bf4b
  8. 26 Apr, 2016 2 commits
    • niteria's avatar
      Kill varSetElems in TcErrors · 2dc5b92e
      niteria authored
      The uses of varSetElems in these places are unnecessary and while it
      doesn't intruduce non-determinism in the ABI the plan is to get
      rid of all varSetElems to get some compile time guarantees.
      
      Test Plan: ./validate
      
      Reviewers: austin, simonmar, bgamari, goldfire, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2141
      
      GHC Trac Issues: #4012
      2dc5b92e
    • niteria's avatar
      Kill varSetElemsWellScoped in quantifyTyVars · c9bcaf31
      niteria authored
      varSetElemsWellScoped introduces unnecessary non-determinism in
      inferred type signatures.
      Removing this instance required changing the representation of
      TcDepVars to use deterministic sets.
      This is the last occurence of varSetElemsWellScoped, allowing me to
      finally remove it.
      
      Test Plan:
      ./validate
      I will update the expected outputs when commiting, some reordering
      of type variables in types is expected.
      
      Reviewers: goldfire, simonpj, austin, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: thomie, simonmar
      
      Differential Revision: https://phabricator.haskell.org/D2135
      
      GHC Trac Issues: #4012
      c9bcaf31
  9. 22 Apr, 2016 1 commit
    • Simon Peyton Jones's avatar
      Warn about simplifiable class constraints · 9421b0c7
      Simon Peyton Jones authored
      Provoked by Trac #11948, this patch adds a new warning to GHC
      
        -Wsimplifiable-class-constraints
      
      It warns if you write a class constraint in a type signature that
      can be simplified by an existing instance declaration.  Almost always
      this means you should simplify it right now; type inference is very
      fragile without it, as #11948 shows.
      
      I've put the warning as on-by-default, but I suppose that if there are
      howls of protest we can move it out (as happened for -Wredundant-constraints.
      
      It actually found an example of an over-complicated context in CmmNode.
      
      Quite a few tests use these weird contexts to trigger something else,
      so I had to suppress the warning in those.
      
      The 'haskeline' library has a few occurrences of the warning (which
      I think should be fixed), so I switched it off for that library in
      warnings.mk.
      
      The warning itself is done in TcValidity.check_class_pred.
      
      HOWEVER, when type inference fails we get a type error; and the error
      suppresses the (informative) warning.  So as things stand, the warning
      only happens when it doesn't cause a problem.  Not sure what to do
      about this, but this patch takes us forward, I think.
      9421b0c7
  10. 04 Apr, 2016 1 commit
    • Simon Peyton Jones's avatar
      Deeply instantiate in :type · f2a2b79f
      Simon Peyton Jones authored
      See Trac #11376 and
       Note [Deeply instantiate in :type] in TcRnDriver
      
      Sadly this showed up one new problem (Trac #11786) and one opportunity
      (Trac #11787), so test T11549 is now marked expect-broken on these two.
      f2a2b79f
  11. 24 Mar, 2016 1 commit
  12. 21 Mar, 2016 4 commits
  13. 17 Mar, 2016 3 commits
    • eir@cis.upenn.edu's avatar
      Fix #11512 by getting visibility right for methods · f4f315a3
      eir@cis.upenn.edu authored
      Test case: typecheck/should_compile/T11512
      f4f315a3
    • eir@cis.upenn.edu's avatar
      Fix #11716. · 3fe87aa0
      eir@cis.upenn.edu authored
      There were several smallish bugs here:
       - We had too small an InScopeSet when rejigging GADT return types.
       - When adding the extra_tvs with a datatype kind signature, we
         were sometimes changing Uniques of an explicitly bound kind var.
       - Using coercionKind in the flattener got the wrong visibility
         for a binder. Now we just zonk to get what we need.
      
      Test case: dependent/should_compile/RaeJobTalk
      3fe87aa0
    • eir@cis.upenn.edu's avatar
      Fix #11711. · b5565f1a
      eir@cis.upenn.edu authored
      There were two bugs here, both simple: we need to filter out
      covars before calling isMetaTyVar in the solver, and TcPat had
      a tcSubType the wrong way round.
      
      test case: dependent/should_compile/T11711
      b5565f1a
  14. 16 Mar, 2016 2 commits
    • eir@cis.upenn.edu's avatar
      Clean up some pretty-printing in errors. · 5d98b8bf
      eir@cis.upenn.edu authored
      It turns out that there were some pretty egregious mistakes
      in the code that suggested -fprint-explicit-kinds, which are
      fixed. This commit also reorders a bunch of error messages,
      which I think is an improvement.
      
      This also adds the test case for #11471, which is what
      triggered the cleanup in TcErrors. Now that #11473 is done,
      there is nothing more outstanding for #11471.
      
      test case: dependent/should_fail/T11471
      5d98b8bf
    • eir@cis.upenn.edu's avatar
      Fix #11473. · aade1112
      eir@cis.upenn.edu authored
      I've added a check in the zonker for representation polymorphism.
      I don't like having this be in the zonker, but I don't know where
      else to put it. It can't go in TcValidity, because a clever enough
      user could convince the solver to do bogus representation polymorphism
      even though there's nothing obviously wrong in what they wrote.
      Note that TcValidity doesn't run over *expressions*, which is where
      this problem arises.
      
      In any case, the check is simple and it works.
      
      test case: dependent/should_fail/T11473
      aade1112
  15. 15 Mar, 2016 3 commits
    • eir@cis.upenn.edu's avatar
      Fix #11648. · 55577a91
      eir@cis.upenn.edu authored
      We now check that a CUSK is really a CUSK and issue an error if
      it isn't. This also involves more solving and zonking in
      kcHsTyVarBndrs, which was the outright bug reported in #11648.
      
      Test cases: polykinds/T11648{,b}
      
      This updates the haddock submodule.
      
      [skip ci]
      55577a91
    • eir@cis.upenn.edu's avatar
      Fix #11334. · 84c773e1
      eir@cis.upenn.edu authored
      Now we fail when trying to default non-*-kinded kind variables
      with -XNoPolyKinds.
      
      test case: dependent/should_fail/T11334
      
      [skip ci]
      84c773e1
    • eir@cis.upenn.edu's avatar
      Fix #11407. · e9bf7bb5
      eir@cis.upenn.edu authored
      This removes the `defer_me` check that was in checkTauTvUpdate
      and uses only a type family check instead. The old defer_me check
      repeated work done by fast_check in occurCheckExpand.
      
      There is also some error message improvement, necessitated by
      the terrible error message that the test case produced, even when
      it didn't consume all of memory.
      
      test case: dependent/should_fail/T11407
      
      [skip ci]
      e9bf7bb5
  16. 27 Feb, 2016 1 commit
  17. 25 Feb, 2016 1 commit
    • barrucadu's avatar
      Print which warning-flag controls an emitted warning · bb5afd3c
      barrucadu authored and Herbert Valerio Riedel's avatar Herbert Valerio Riedel committed
      Both gcc and clang tell which warning flag a reported warning can be
      controlled with, this patch makes ghc do the same. More generally, this
      allows for annotated compiler output, where an optional annotation is
      displayed in brackets after the severity.
      
      This also adds a new flag `-f(no-)show-warning-groups` to control
      whether to show which warning-group (such as `-Wall` or `-Wcompat`)
      a warning belongs to. This flag is on by default.
      
      This implements #10752
      
      Reviewed By: quchen, bgamari, hvr
      
      Differential Revision: https://phabricator.haskell.org/D1943
      bb5afd3c
  18. 24 Feb, 2016 1 commit
    • eir@cis.upenn.edu's avatar
      Address #11471 by putting RuntimeRep in kinds. · d8c64e86
      eir@cis.upenn.edu authored
      See Note [TYPE] in TysPrim. There are still some outstanding
      pieces in #11471 though, so this doesn't actually nail the bug.
      
      This commit also contains a few performance improvements:
      
      * Short-cut equality checking of nullary type syns
      
      * Compare types before kinds in eqType
      
      * INLINE coreViewOneStarKind
      
      * Store tycon binders separately from kinds.
      
      This resulted in a ~10% performance improvement in compiling
      the Cabal package. No change in functionality other than
      performance. (This affects the interface file format, though.)
      
      This commit updates the haddock submodule.
      d8c64e86
  19. 17 Feb, 2016 1 commit
    • eir@cis.upenn.edu's avatar
      Fix #11241. · 43468fe3
      eir@cis.upenn.edu authored
      When renaming a type, now looks for wildcards in bound variables'
      kinds.
      
      testcase: dependent/should_compile/T11241
      43468fe3
  20. 29 Jan, 2016 1 commit
  21. 26 Jan, 2016 2 commits
    • 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
      Add "ticks-exhausted" comment · 47b3f588
      Simon Peyton Jones authored
      This code deliberately builds a subtle negative-occurrence-of-data-type
      example, described in the paper, so with -O it'll give "simplifier
      ticks exhausted".
      
      This patch just adds a comment to explain.
      47b3f588
  22. 15 Jan, 2016 3 commits
    • eir@cis.upenn.edu's avatar
      Fix #11405. · 3c6635ef
      eir@cis.upenn.edu authored
      This adds a new variant of AbsBinds that is used solely for bindings
      with a type signature. This allows for a simpler desugaring that
      does not produce the bogus output that tripped up Core Lint in
      ticket #11405. Should make other desugarings simpler, too.
      3c6635ef
    • eir@cis.upenn.edu's avatar
      Constrained types have kind * in validity check. · bafbde7e
      eir@cis.upenn.edu authored
      This addresses #11405, but a deeper problem lurks.
      Try test dependent/should_compile/T11405 and see comment:3
      on the ticket.
      bafbde7e
    • eir@cis.upenn.edu's avatar
      Fix #11311 · 6c07f142
      eir@cis.upenn.edu authored
      All things of kind *, including * itself, need to have a PtrRep.
      
      Test: dependent/should_compile/T11311
      6c07f142
  23. 26 Dec, 2015 1 commit
  24. 14 Dec, 2015 2 commits
  25. 12 Dec, 2015 1 commit
  26. 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