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. 12 Aug, 2018 1 commit
    • Ryan Scott's avatar
      Suppress redundant givens during error reporting · c552feea
      Ryan Scott authored
      Summary:
      When GHC reports that it cannot solve a constraint in error
      messages, it often reports what given constraints it has in scope.
      Unfortunately, sometimes redundant constraints (like `* ~ *`, from
      #15361) can sneak in. The fix is simple: blast away these redundant
      constraints using `mkMinimalBySCs`.
      
      Test Plan: make test TEST=T15361
      
      Reviewers: simonpj, bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #15361
      
      Differential Revision: https://phabricator.haskell.org/D5002
      c552feea
  2. 25 Jul, 2018 1 commit
    • Simon Peyton Jones's avatar
      Set GenSigCtxt for the argument part of tcSubType · 12c0f03a
      Simon Peyton Jones authored
      The reason for this change is described in TcUnify
      Note [Settting the argument context], and Trac #15438.
      
      The only effect is on error messages, where it stops GHC
      reporting an outright falsity (about the type signature for
      a function) when it finds an errors in a higher-rank situation.
      
      The testsuite changes in this patch illustrate the problem.
      12c0f03a
  3. 11 Jul, 2018 1 commit
    • Ryan Scott's avatar
      Use IfaceAppArgs to store an IfaceAppTy's arguments · 1c353623
      Ryan Scott authored
      Summary:
      Currently, an `IfaceAppTy` has no way to tell whether its
      argument is visible or not, so it simply treats all arguments as
      visible, leading to #15330. We already have a solution for this
      problem in the form of the `IfaceTcArgs` data structure, used by
      `IfaceTyConApp` to represent the arguments to a type constructor.
      Therefore, it makes sense to reuse this machinery for `IfaceAppTy`,
      so this patch does just that.
      
      This patch:
      
      1. Renames `IfaceTcArgs` to `IfaceAppArgs` to reflect its more
         general purpose.
      2. Changes the second field of `IfaceAppTy` from `IfaceType` to
         `IfaceAppArgs`, and propagates the necessary changes through. In
         particular, pretty-printing an `IfaceAppTy` now goes through the
         `IfaceAppArgs` pretty-printer, which correctly displays arguments
         as visible or not for free, fixing #15330.
      3. Changes `toIfaceTypeX` and related functions so that when
         converting an `AppTy` to an `IfaceAppTy`, it flattens as many
         argument `AppTy`s as possible, and then converts those arguments
         into an `IfaceAppArgs` list, using the kind of the function
         `Type` as a guide. (Doing so minimizes the number of times we need
         to call `typeKind`, which is more expensive that finding the kind
         of a `TyCon`.)
      
      Test Plan: make test TEST=T15330
      
      Reviewers: goldfire, simonpj, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #15330
      
      Differential Revision: https://phabricator.haskell.org/D4938
      1c353623
  4. 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
  5. 03 Jun, 2018 1 commit
    • Tobias Dammers's avatar
      Turn "inaccessible code" error into a warning · 08073e16
      Tobias Dammers authored
      With GADTs, it is possible to write programs such that the type
      constraints make some code branches inaccessible.
      
      Take, for example, the following program ::
      
          {-# LANGUAGE GADTs #-}
      
          data Foo a where
           Foo1 :: Foo Char
           Foo2 :: Foo Int
      
          data TyEquality a b where
                  Refl :: TyEquality a a
      
          checkTEQ :: Foo t -> Foo u -> Maybe (TyEquality t u)
          checkTEQ x y = error "unimportant"
      
          step2 :: Bool
          step2 = case checkTEQ Foo1 Foo2 of
                   Just Refl -> True -- Inaccessible code
                   Nothing -> False
      
      Clearly, the `Just Refl` case cannot ever be reached, because the `Foo1`
      and `Foo2` constructors say `t ~ Char` and `u ~ Int`, while the `Refl`
      constructor essentially mandates `t ~ u`, and thus `Char ~ Int`.
      
      Previously, GHC would reject such programs entirely; however, in
      practice this is too harsh. Accepting such code does little harm, since
      attempting to use the "impossible" code will still produce errors down
      the chain, while rejecting it means we cannot legally write or generate
      such code at all.
      
      Hence, we turn the error into a warning, and provide
      `-Winaccessible-code` to control GHC's behavior upon encountering this
      situation.
      
      Test Plan: ./validate
      
      Reviewers: bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #11066
      
      Differential Revision: https://phabricator.haskell.org/D4744
      08073e16
  6. 18 May, 2018 2 commits
    • Simon Peyton Jones's avatar
      Orient TyVar/TyVar equalities with deepest on the left · 2bbdd00c
      Simon Peyton Jones authored
      Trac #15009 showed that, for Given TyVar/TyVar equalities, we really
      want to orient them with the deepest-bound skolem on the left. As it
      happens, we also want to do the same for Wanteds, but for a different
      reason (more likely to be touchable).  Either way, deepest wins:
      see TcUnify Note [Deeper level on the left].
      
      This observation led me to some significant changes:
      
      * A SkolemTv already had a TcLevel, but the level wasn't really being
        used.   Now it is!
      
      * I updated added invariant (SkolInf) to TcType
        Note [TcLevel and untouchable type variables], documenting that
        the level number of all the ic_skols should be the same as the
        ic_tclvl of the implication
      
      * FlatSkolTvs and FlatMetaTvs previously had a dummy level-number of
        zero, which messed the scheme up.   Now they get a level number the
        same way as all other TcTyVars, instead of being a special case.
      
      * To make sure that FlatSkolTvs and FlatMetaTvs are untouchable (which
        was previously done via their magic zero level) isTouchableMetaTyVar
        just tests for those two cases.
      
      * TcUnify.swapOverTyVars is the crucial orientation function; see the
        new Note [TyVar/TyVar orientation].  I completely rewrote this function,
        and it's now much much easier to understand.
      
      I ended up doing some related refactoring, of course
      
      * I noticed that tcImplicitTKBndrsX and tcExplicitTKBndrsX were doing
        a lot of useless work in the case where there are no skolems; I
        added a fast-patch
      
      * Elminate the un-used tcExplicitTKBndrsSig; and thereby get rid of
        the higher-order parameter to tcExpliciTKBndrsX.
      
      * Replace TcHsType.emitTvImplication with TcUnify.checkTvConstraints,
        by analogy with TcUnify.checkConstraints.
      
      * Inline TcUnify.buildImplication into its only call-site in
        TcUnify.checkConstraints
      
      * TcS.buildImplication becomes TcS.CheckConstraintsTcS, with a
        simpler API
      
      * Now that we have NoEvBindsVar we have no need of termEvidenceAllowed;
        nuke the latter, adding Note [No evidence bindings] to TcEvidence.
      2bbdd00c
    • Ryan Scott's avatar
      Add regression tests for #11515 and #12563 · 819b9cfd
      Ryan Scott authored
      Happily, both of these issues appear to have been fixed in GHC 8.2.
      Let's add regression tests for them to ensure that they stay fixed.
      819b9cfd
  7. 13 May, 2018 1 commit
  8. 05 May, 2018 1 commit
  9. 03 May, 2018 1 commit
  10. 02 Apr, 2018 1 commit
  11. 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
  12. 19 Mar, 2018 1 commit
    • Ryan Scott's avatar
      Don't permit data types with return kind Constraint · f748c529
      Ryan Scott authored
      Previously, GHC allowed all of the following:
      
      ```lang=haskell
      data Foo1 :: Constraint
      data family Foo2 :: Constraint
      data family Foo3 :: k
      data instance Foo3 :: Constraint
      ```
      
      Yikes! This is because GHC was confusing `Type` with `Constraint`
      due to careless use of the `isLiftedTypeKind` function. To respect
      this distinction, I swapped `isLiftedTypeKind` out for
      `tcIsStarKind`—which does respect this distinction—in the right
      places.
      
      Test Plan: make test TEST="T14048a T14048b T14048c"
      
      Reviewers: bgamari
      
      Reviewed By: bgamari
      
      Subscribers: goldfire, rwbarton, thomie, carter
      
      GHC Trac Issues: #14048
      
      Differential Revision: https://phabricator.haskell.org/D4479
      f748c529
  13. 27 Feb, 2018 1 commit
  14. 18 Feb, 2018 1 commit
  15. 03 Jan, 2018 2 commits
    • Simon Peyton Jones's avatar
      No deferred type errors under a forall · 298ec78c
      Simon Peyton Jones authored
      As Trac #14605 showed, we can't defer a type error under a
      'forall' (when unifying two forall types).
      
      The fix is simple.
      298ec78c
    • Simon Peyton Jones's avatar
      Fix OptCoercion · 9e5535ca
      Simon Peyton Jones authored
      In the presence of -fdefer-type-errors, OptCoercion can
      encounter a mal-formed coerercion with type
          T a ~ T a b
      and that was causing a subsequent Lint error.
      
      This caused Trac #14607.  Easily fixed by turning an ASSERT
      into a guard.
      9e5535ca
  16. 26 Dec, 2017 1 commit
    • 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
  17. 22 Nov, 2017 1 commit
    • Evan Rutledge Borden's avatar
      Add warn-missing-export-lists · 63e4ac37
      Evan Rutledge Borden authored
      Many industrial users have aligned around the idea that implicit exports
      are an anti-pattern. They lead to namespace pollution and byzantine
      naming schemes. They also prevent GHC's dead code analysis and create
      more obstacles to optimization. This warning allows teams/projects to
      warn on or enforce via -Werror explicit export lists.
      
      This warning also serves as a complement to warn-missing-import-lists.
      
      This was originally discussed here:
      https://github.com/ghc-proposals/ghc-proposals/pull/93
      
      Test Plan: Three new minimal tests have been added to the type checker.
      
      Reviewers: bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D4197
      63e4ac37
  18. 30 Oct, 2017 1 commit
    • Ryan Scott's avatar
      Fix #14390 by making toIfaceTyCon aware of equality · 85aa1f42
      Ryan Scott authored
      GHC was panicking when pretty-printing a heterogeneous
      equality type constructor (#14390) because the function which
      produced the type constructor, `toIfaceTyCon`, wasn't attaching the
      appropriate `IfaceTyConSort` for equality type constructors, which
      is `IfaceEqualityTyCon`. This is fixed easily enough.
      
      Test Plan: make test TEST=T14390
      
      Reviewers: austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #14390
      
      Differential Revision: https://phabricator.haskell.org/D4132
      85aa1f42
  19. 18 Oct, 2017 1 commit
    • Simon Peyton Jones's avatar
      Don't deeply expand insolubles · 74cd1be0
      Simon Peyton Jones authored
      Trac #13450 went bananas if we expand insoluble constraints.
      Better just to leave them un-expanded.
      
      I'm not sure in detail about why it goes so badly wrong; but
      regardless, the less we mess around with insoluble contraints
      the better the error messages will be.
      74cd1be0
  20. 11 Oct, 2017 1 commit
  21. 26 Sep, 2017 1 commit
  22. 21 Sep, 2017 1 commit
  23. 14 Sep, 2017 3 commits
  24. 22 Aug, 2017 1 commit
    • Ryan Scott's avatar
      Revise function arity mismatch errors involving TypeApplications · 84760976
      Ryan Scott authored
      Summary:
      Currently, whenever you apply a function to too many arguments and
      some of those arguments happen to be visible type applications, the error
      message that GHC gives is rather confusing. Consider the message you receive
      when typechecking `id @Int 1 2`:
      
      ```
      The function `id` is applied to three arguments,
      but its type `Int -> Int` has only one
      ```
      
      This is baffling, since the two lines treat the visible type argument `@Int`
      differently. The top line ("applied to three arguments") includes `@Int`,
      whereas the bottom line ("has only one") excludes `@Int` from consideration.
      
      There are multiple ways one could fix this, which I explain in an addendum to
      `Note [Herald for matchExpectedFunTys]`. The approach adopted here is to change
      the herald of this error message to include visible type arguments, and to
      avoid counting them in the "applied to n arguments" part of the error. The end
      result is that the new error message for `id @Int 1 2` is now:
      
      ```
      The expression `id @Int` is applied to two arguments,
      but its type `Int -> Int` has only one
      ```
      
      Test Plan: make test TEST=T13902
      
      Reviewers: goldfire, austin, bgamari
      
      Reviewed By: goldfire
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #13902
      
      Differential Revision: https://phabricator.haskell.org/D3868
      84760976
  25. 17 Aug, 2017 1 commit
    • Ryan Scott's avatar
      Remove unneeded reqlibs for mtl and parsec in the GHC testsuite · 03853475
      Ryan Scott authored
      Now that `mtl` and `parsec` are boot libraries, there's no need to
      qualify various tests in the testsuite with `reqlib('mtl')` or
      `reqlib('parsec')`.
      
      Test Plan: make test TEST="T4809 tcfail126 T4355 tc232 tc223 tc220
      tc217 tc183 T5303 DoParamM qq005 qq006 galois_raytrace T1074 mod133
      T3787 T4316 prog011 drvfail006 drvfail008"
      
      Reviewers: bgamari, austin
      
      Subscribers: rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3855
      03853475
  26. 29 Jul, 2017 1 commit
  27. 28 Jul, 2017 1 commit
    • Simon Peyton Jones's avatar
      Do not discard insolubles in implications · 452755de
      Simon Peyton Jones authored
      Trac #14000 showed up two errors
      
      * In TcRnTypes.dropInsolubles we dropped all implications, which
        might contain the very insolubles we wanted to keep.  This was
        an outright error, and is why the out-of-scope error was actually
        lost altogether in Trac #14000
      
      * In TcSimplify.simplifyInfer, if there are definite (insoluble)
        errors, it's better to suppress the following ambiguity test,
        because the type may be bogus anyway.  See TcSimplify
        Note [Quantification with errors].  This fix seems a bit clunky,
        but it'll do for now.
      452755de
  28. 27 Jul, 2017 4 commits
    • Richard Eisenberg's avatar
      Fix #11963 by checking for more mixed type/kinds · 10d13b62
      Richard Eisenberg authored
      This is a straightforward fix -- there were just some omitted
      checks.
      
      test case: typecheck/should_fail/T11963
      10d13b62
    • Richard Eisenberg's avatar
      Fix #13819 by refactoring TypeEqOrigin.uo_thing · c2417b87
      Richard Eisenberg authored
      The uo_thing field of TypeEqOrigin is used to track the
      "thing" (either term or type) that has the type (kind) stored
      in the TypeEqOrigin fields. Previously, this was sometimes a
      proper Core Type, which needed zonking and tidying. Now, it
      is only HsSyn: much simpler, and the error messages now use
      the user-written syntax.
      
      But this aspect of uo_thing didn't cause #13819; it was the
      sibling field uo_arity that did. uo_arity stored the number
      of arguments of uo_thing, useful when reporting something
      like "should have written 2 fewer arguments". We wouldn't want
      to say that if the thing didn't have two arguments. However,
      in practice, GHC was getting this wrong, and this message
      didn't seem all that helpful. Furthermore, the calculation
      of the number of arguments is what caused #13819 to fall over.
      This patch just removes uo_arity. In my opinion, the change
      to error messages is a nudge in the right direction.
      
      Test case: typecheck/should_fail/T13819
      c2417b87
    • Richard Eisenberg's avatar
      Test #11672 in typecheck/should_fail/T11672. · 9a549756
      Richard Eisenberg authored
      I believe this was fixed with the fix for #11198.
      9a549756
    • Richard Eisenberg's avatar
      Improve error messages around kind mismatches. · 8e15e3d3
      Richard Eisenberg authored
      Previously, when canonicalizing (or unifying, in uType) a
      heterogeneous equality, we emitted a kind equality and used the
      resulting coercion to cast one side of the heterogeneous equality.
      
      While sound, this led to terrible error messages. (See the bugs
      listed below.) The problem is that using the coercion built from
      the emitted kind equality is a bit like a wanted rewriting a wanted.
      The solution is to keep heterogeneous equalities as irreducible.
      
      See Note [Equalities with incompatible kinds] in TcCanonical.
      
      This commit also removes a highly suspicious switch to FM_SubstOnly
      when flattening in the kinds of a type variable. I have no idea
      why this was there, other than as a holdover from pre-TypeInType.
      I've not left a Note because there is simply no reason I can conceive
      of that the FM_SubstOnly should be there.
      
      One challenge with this patch is that the emitted derived equalities
      might get emitted several times: when a heterogeneous equality is
      in an implication and then gets floated out from the implication,
      the Derived is present both in and out of the implication. This
      causes a duplicate error message. (Test case:
      typecheck/should_fail/T7368) Solution: track the provenance of
      Derived constraints and refuse to float out a constraint that has
      an insoluble Derived.
      
      Lastly, this labels one test (dependent/should_fail/RAE_T32a)
      as expect_broken, because the problem is really #12919. The
      different handling of constraints in this patch exposes the error.
      
      This fixes bugs #11198, #12373, #13530, and #13610.
      
      test cases:
      typecheck/should_fail/{T8262,T8603,tcail122,T12373,T13530,T13610}
      8e15e3d3
  29. 19 Jul, 2017 1 commit
    • Ryan Scott's avatar
      Fix #13983 by creating a TyConFlavour type, and using it · 6e3c901d
      Ryan Scott authored
      An error message was referring to a type synonym as a datatype.
      Annoyingly, learning that the TyCon over which the error message is
      operating is actually a type synonym was previously impossible, since
      that code only had access to a TcTyCon, which doesn't retain any
      information about what sort of TyCon it is.
      
      To rectify this, I created a new TyConFlavour datatype, intended to
      capture roughly what sort of TyCon we're dealing with. I then performing
      the necessary plumbing to ensure all TcTyCons have a TyConFlavour, and
      propagated this information through to the relevant error message.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, austin, bgamari, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: simonpj, rwbarton, thomie
      
      GHC Trac Issues: #13983
      
      Differential Revision: https://phabricator.haskell.org/D3747
      6e3c901d
  30. 03 Jul, 2017 1 commit
    • Ryan Scott's avatar
      Fix #13311 by using tcSplitNestedSigmaTys in the right place · c3a78623
      Ryan Scott authored
      Previously, we we only using `tcSplitSigmaTy` when determining if a
      function had been applied to too few arguments, so it wouldn't work for
      functions with nested `forall`s. Thankfully, this is easily fixed with a
      dash of `tcSplitNestedSigmaTys`.
      
      Test Plan: make test TEST=T13311
      
      Reviewers: austin, bgamari, simonpj
      
      Reviewed By: bgamari
      
      Subscribers: goldfire, simonpj, rwbarton, thomie
      
      GHC Trac Issues: #13311
      
      Differential Revision: https://phabricator.haskell.org/D3678
      c3a78623
  31. 19 Jun, 2017 1 commit
  32. 27 May, 2017 1 commit
  33. 12 May, 2017 1 commit