1. 21 Mar, 2019 1 commit
    • Ryan Scott's avatar
      Reject nested predicates in impredicativity checking · 8d18a873
      Ryan Scott authored
      When GHC attempts to unify a metavariable with a type containing
      foralls, it will be rejected as an occurrence of impredicativity.
      GHC was /not/ extending the same treatment to predicate types, such
      as in the following (erroneous) example from #11514:
      
      ```haskell
      foo :: forall a. (Show a => a -> a) -> ()
      foo = undefined
      ```
      
      This will attempt to instantiate `undefined` at
      `(Show a => a -> a) -> ()`, which is impredicative. This patch
      catches impredicativity arising from predicates in this fashion.
      
      Since GHC is pickier about impredicative instantiations, some test
      cases needed to be updated to be updated so as not to fall afoul of
      the new validity check. (There were a surprising number of
      impredicative uses of `undefined`!) Moreover, the `T14828` test case
      now has slightly less informative types shown with `:print`. This is
      due to a a much deeper issue with the GHCi debugger (see #14828).
      
      Fixes #11514.
      8d18a873
  2. 15 Mar, 2019 1 commit
  3. 14 Mar, 2019 1 commit
  4. 12 Mar, 2019 1 commit
    • Simon Peyton Jones's avatar
      Use transSuperClasses in TcErrors · 50249a9f
      Simon Peyton Jones authored
      Code in TcErrors was recursively using immSuperClasses,
      which loops in the presence of UndecidableSuperClasses.
      
      Better to use transSuperClasses instead, which has a loop-breaker
      mechanism built in.
      
      Fixes issue #16414.
      50249a9f
  5. 11 Mar, 2019 1 commit
    • Alec Theriault's avatar
      Ignore more version numbers in the testsuite · bcb6769c
      Alec Theriault authored
      Prevents some tests from failing just due to mismatched version numbers.
      
      These version numbers shouldn't cause tests to fail, especially since
      we *expect* them to be regularly incremented. The motivation for this
      particular set of changes came from the changes that came along with
      the `base` version bump in 8f19ecc9.
      bcb6769c
  6. 24 Feb, 2019 1 commit
    • Simon Peyton Jones's avatar
      Add AnonArgFlag to FunTy · 6cce36f8
      Simon Peyton Jones authored
      The big payload of this patch is:
      
        Add an AnonArgFlag to the FunTy constructor
        of Type, so that
          (FunTy VisArg   t1 t2) means (t1 -> t2)
          (FunTy InvisArg t1 t2) means (t1 => t2)
      
      The big payoff is that we have a simple, local test to make
      when decomposing a type, leading to many fewer calls to
      isPredTy. To me the code seems a lot tidier, and probably
      more efficient (isPredTy has to take the kind of the type).
      
      See Note [Function types] in TyCoRep.
      
      There are lots of consequences
      
      * I made FunTy into a record, so that it'll be easier
        when we add a linearity field, something that is coming
        down the road.
      
      * Lots of code gets touched in a routine way, simply because it
        pattern matches on FunTy.
      
      * I wanted to make a pattern synonym for (FunTy2 arg res), which
        picks out just the argument and result type from the record. But
        alas the pattern-match overlap checker has a heart attack, and
        either reports false positives, or takes too long.  In the end
        I gave up on pattern synonyms.
      
        There's some commented-out code in TyCoRep that shows what I
        wanted to do.
      
      * Much more clarity about predicate types, constraint types
        and (in particular) equality constraints in kinds.  See TyCoRep
        Note [Types for coercions, predicates, and evidence]
        and Note [Constraints in kinds].
      
        This made me realise that we need an AnonArgFlag on
        AnonTCB in a TyConBinder, something that was really plain
        wrong before. See TyCon Note [AnonTCB InivsArg]
      
      * When building function types we must know whether we
        need VisArg (mkVisFunTy) or InvisArg (mkInvisFunTy).
        This turned out to be pretty easy in practice.
      
      * Pretty-printing of types, esp in IfaceType, gets
        tidier, because we were already recording the (->)
        vs (=>) distinction in an ad-hoc way.  Death to
        IfaceFunTy.
      
      * mkLamType needs to keep track of whether it is building
        (t1 -> t2) or (t1 => t2).  See Type
        Note [mkLamType: dictionary arguments]
      
      Other minor stuff
      
      * Some tidy-up in validity checking involving constraints;
        Trac #16263
      6cce36f8
  7. 16 Feb, 2019 2 commits
  8. 12 Feb, 2019 1 commit
    • Richard Eisenberg's avatar
      Fix #16188 · 4a4ae70f
      Richard Eisenberg authored
      There was an awful lot of zipping going on in
      canDecomposableTyConAppOK, and one of the lists being zipped
      was too short, causing the result to be too short. Easily
      fixed.
      
      Also fixes #16204 and #16225
      
      test case: typecheck/should_compile/T16188
                 typecheck/should_compile/T16204[ab]
                 typecheck/should_fail/T16204c
                 typecheck/should_compile/T16225
      4a4ae70f
  9. 07 Feb, 2019 1 commit
  10. 02 Feb, 2019 1 commit
  11. 30 Jan, 2019 3 commits
  12. 15 Jan, 2019 1 commit
    • Ryan Scott's avatar
      Control validity-checking of type synonym applications more carefully · 9dc56b61
      Ryan Scott authored
      Trac #16059 shows that when validity checking applications of type
      synonyms, GHC sometimes wasn't checking the expanded type enough.
      We must be careful, however, since checking both the expanded type as
      well as the arguments to the type synonym can lead to exponential
      blowup (see https://ghc.haskell.org/trac/ghc/ticket/16059#comment:4).
      Nor can we omit checking either the expanded type or the argument for
      correctness reasons.
      
      The solution here is to introduce a new `ExpandMode` data type that
      is plumbed through all of the type-validity-checking functions in
      `TcValidity`. `ExpandMode` dictates whether we only check the
      expanded type (`Expand`), only check the arguments (`NoExpand), or
      both (`Both`). Importantly, if we check `Both` in the function for
      validity checking type synonym applications, then we switch to
      `NoExpand` when checking the arguments so as to avoid exponential
      blowup. See `Note [Correctness and performance of type synonym validity
      checking]` for the full story.
      9dc56b61
  13. 03 Jan, 2019 1 commit
    • My Nguyen's avatar
      Visible kind application · 17bd1635
      My Nguyen authored
      Summary:
      This patch implements visible kind application (GHC Proposal 15/#12045), as well as #15360 and #15362.
      It also refactors unnamed wildcard handling, and requires that type equations in type families in Template Haskell be
      written with full type on lhs. PartialTypeSignatures are on and warnings are off automatically with visible kind
      application, just like in term-level.
      
      There are a few remaining issues with this patch, as documented in
      ticket #16082.
      
      Includes a submodule update for Haddock.
      
      Test Plan: Tests T12045a/b/c/TH1/TH2, T15362, T15592a
      
      Reviewers: simonpj, goldfire, bgamari, alanz, RyanGlScott, Iceland_jack
      
      Subscribers: ningning, Iceland_jack, RyanGlScott, int-index, rwbarton, mpickering, carter
      
      GHC Trac Issues: `#12045`, `#15362`, `#15592`, `#15788`, `#15793`, `#15795`, `#15797`, `#15799`, `#15801`, `#15807`, `#15816`
      
      Differential Revision: https://phabricator.haskell.org/D5229
      17bd1635
  14. 20 Dec, 2018 1 commit
    • Simon Peyton Jones's avatar
      Refine the suppression of RuntimeRep variables · 5f2a8793
      Simon Peyton Jones authored
      When we pretty-print types, we suppress RuntimeRep variables, but
      we were being too aggressive in doing so, resulting in Trac #16074.
      
      This patch makes the suppression a bit less aggressive.
      See Note [Defaulting RuntimeRep variables]
      5f2a8793
  15. 13 Dec, 2018 1 commit
    • Ben Gamari's avatar
      testsuite: Normalise away spurious differences in out-of-scope instances · 9d9f4c9a
      Ben Gamari authored
      This fixes a variety of testsuite failures with integer-simple of the form
      
      ```
      --- typecheck/should_fail/tcfail072.run/tcfail072.stderr.normalised
      +++ typecheck/should_fail/tcfail072.run/tcfail072.comp.stderr.normalised
      @@ -12,7 +12,7 @@
                 -- Defined in ‘integer-<IMPL>-<VERSION>:GHC.Integer.Type’
               instance Ord () -- Defined in ‘GHC.Classes’
               ...plus 21 others
      -        ...plus three instances involving out-of-scope types
      +        ...plus two instances involving out-of-scope types
               (use -fprint-potential-instances to see them all)
            In the expression: g A
             In an equation for ‘g’: g (B _ _) = g A
      ```
      
      In service of fixing #16043.
      9d9f4c9a
  16. 07 Dec, 2018 1 commit
    • Ryan Scott's avatar
      Fix #12102/#15872 by removing outdated users' guide prose · 73cce63f
      Ryan Scott authored
      Summary:
      In the beginning, #12102 (and #15872, which is of a similar
      ilk) were caused by a poor, confused user trying to use code that
      looks like this (with a constraint in the kind of a data type):
      
      ```lang=haskell
      type family IsTypeLit a where
        IsTypeLit Nat    = 'True
        IsTypeLit Symbol = 'True
        IsTypeLit a      = 'False
      
      data T :: forall a. (IsTypeLit a ~ 'True) => a -> * where
        MkNat    :: T 42
        MkSymbol :: T "Don't panic!"
      ```
      
      Many bizarre GHC quirks (documented in those tickets) arose from
      this sort of construction. Ultimately, the use of constraints in
      data type kinds like this has made a lot of people very confused and
      been widely regarded as a bad move.
      
      Commit 2257a86d finally put this
      feature out of its misery, so now the code above simply errors with
      `Illegal constraint in a kind`. As a result, the aforementioned
      tickets are moot, so this patch wraps a bow on the whole thing by:
      
      1. Removing the (now outdated) section on constraints in data type
         kinds from the users' guide, and
      2. Adding a test case to test this code path.
      
      Test Plan: make test TEST=T12102
      
      Reviewers: goldfire, simonpj, bgamari, tdammers
      
      Reviewed By: tdammers
      
      Subscribers: tdammers, rwbarton, carter
      
      GHC Trac Issues: #12102, #15872
      
      Differential Revision: https://phabricator.haskell.org/D5397
      73cce63f
  17. 03 Dec, 2018 1 commit
    • Ryan Scott's avatar
      Fix #15954 by rejigging check_type's order · 2e6cc3d0
      Ryan Scott authored
      Summary:
      Previously, `check_type` (which catches illegal uses of
      unsaturated type synonyms without enabling `LiberalTypeSynonyms`,
      among other things) always checks for uses of polytypes before
      anything else. There is a problem with this plan, however:
      checking for polytypes requires decomposing `forall`s and other
      invisible arguments, an action which itself expands type synonyms!
      Therefore, if we have something like:
      
      ```lang=haskell
      type A a = Int
      type B (a :: Type -> Type) = forall x. x -> x
      type C = B A
      ```
      
      Then when checking `B A`, `A` will get expanded to `forall x. x -> x`
      before `check_type` has an opportunity to realize that `A` is an
      unsaturated type synonym! This is the root cause of #15954.
      
      This patch fixes the issue by moving the case of `check_type` that
      detects polytypes to be //after// the case that checks for
      `TyConApp`s. That way, the `TyConApp` case will properly flag things
      like the unsaturated use of `A` in the example above before we ever
      attempt to check for polytypes.
      
      Test Plan: make test TEST=T15954
      
      Reviewers: simonpj, bgamari, goldfire
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15954
      
      Differential Revision: https://phabricator.haskell.org/D5402
      2e6cc3d0
  18. 29 Nov, 2018 2 commits
    • Chaitanya Koparkar's avatar
      Add a test case for #15962 · 8d7496c4
      Chaitanya Koparkar authored
      Test Plan: make test TEST=T15962
      
      Reviewers: RyanGlScott, bgamari
      
      Reviewed By: RyanGlScott
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15962
      
      Differential Revision: https://phabricator.haskell.org/D5393
      8d7496c4
    • Simon Peyton Jones's avatar
      Taming the Kind Inference Monster · 2257a86d
      Simon Peyton Jones authored
      My original goal was (Trac #15809) to move towards using level numbers
      as the basis for deciding which type variables to generalise, rather
      than searching for the free varaibles of the environment.  However
      it has turned into a truly major refactoring of the kind inference
      engine.
      
      Let's deal with the level-numbers part first:
      
      * Augment quantifyTyVars to calculate the type variables to
        quantify using level numbers, and compare the result with
        the existing approach.  That is; no change in behaviour,
        just a WARNing if the two approaches give different answers.
      
      * To do this I had to get the level number right when calling
        quantifyTyVars, and this entailed a bit of care, especially
        in the code for kind-checking type declarations.
      
      * However, on the way I was able to eliminate or simplify
        a number of calls to solveEqualities.
      
      This work is incomplete: I'm not /using/ level numbers yet.
      When I subsequently get rid of any remaining WARNings in
      quantifyTyVars, that the level-number answers differ from
      the current answers, then I can rip out the current
      "free vars of the environment" stuff.
      
      Anyway, this led me into deep dive into kind inference for type and
      class declarations, which is an increasingly soggy part of GHC.
      Richard already did some good work recently in
      
         commit 5e45ad10
         Date:   Thu Sep 13 09:56:02 2018 +0200
      
          Finish fix for #14880.
      
          The real change that fixes the ticket is described in
          Note [Naughty quantification candidates] in TcMType.
      
      but I kept turning over stones. So this patch has ended up
      with a pretty significant refactoring of that code too.
      
      Kind inference for types and classes
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      * Major refactoring in the way we generalise the inferred kind of
        a TyCon, in kcTyClGroup.  Indeed, I made it into a new top-level
        function, generaliseTcTyCon.  Plus a new Note to explain it
        Note [Inferring kinds for type declarations].
      
      * We decided (Trac #15592) not to treat class type variables specially
        when dealing with Inferred/Specified/Required for associated types.
        That simplifies things quite a bit. I also rewrote
        Note [Required, Specified, and Inferred for types]
      
      * Major refactoring of the crucial function kcLHsQTyVars:
        I split it into
             kcLHsQTyVars_Cusk  and  kcLHsQTyVars_NonCusk
        because the two are really quite different. The CUSK case is
        almost entirely rewritten, and is much easier because of our new
        decision not to treat the class variables specially
      
      * I moved all the error checks from tcTyClTyVars (which was a bizarre
        place for it) into generaliseTcTyCon and/or the CUSK case of
        kcLHsQTyVars.  Now tcTyClTyVars is extremely simple.
      
      * I got rid of all the all the subtleties in tcImplicitTKBndrs. Indeed
        now there is no difference between tcImplicitTKBndrs and
        kcImplicitTKBndrs; there is now a single bindImplicitTKBndrs.
        Same for kc/tcExplicitTKBndrs.  None of them monkey with level
        numbers, nor build implication constraints.  scopeTyVars is gone
        entirely, as is kcLHsQTyVarBndrs. It's vastly simpler.
      
        I found I could get rid of kcLHsQTyVarBndrs entirely, in favour of
        the bnew bindExplicitTKBndrs.
      
      Quantification
      ~~~~~~~~~~~~~~
      * I now deal with the "naughty quantification candidates"
        of the previous patch in candidateQTyVars, rather than in
        quantifyTyVars; see Note [Naughty quantification candidates]
        in TcMType.
      
        I also killed off closeOverKindsCQTvs in favour of the same
        strategy that we use for tyCoVarsOfType: namely, close over kinds
        at the occurrences.
      
        And candidateQTyVars no longer needs a gbl_tvs argument.
      
      * Passing the ContextKind, rather than the expected kind itself,
        to tc_hs_sig_type_and_gen makes it easy to allocate the expected
        result kind (when we are in inference mode) at the right level.
      
      Type families
      ~~~~~~~~~~~~~~
      * I did a major rewrite of the impenetrable tcFamTyPats. The result
        is vastly more comprehensible.
      
      * I got rid of kcDataDefn entirely, quite a big function.
      
      * I re-did the way that checkConsistentFamInst works, so
        that it allows alpha-renaming of invisible arguments.
      
      * The interaction of kind signatures and family instances is tricky.
          Type families: see Note [Apparently-nullary families]
          Data families: see Note [Result kind signature for a data family instance]
                         and Note [Eta-reduction for data families]
      
      * The consistent instantation of an associated type family is tricky.
        See Note [Checking consistent instantiation] and
            Note [Matching in the consistent-instantation check]
        in TcTyClsDecls.  It's now checked in TcTyClsDecls because that is
        when we have the relevant info to hand.
      
      * I got tired of the compromises in etaExpandFamInst, so I did the
        job properly by adding a field cab_eta_tvs to CoAxBranch.
        See Coercion.etaExpandCoAxBranch.
      
      tcInferApps and friends
      ~~~~~~~~~~~~~~~~~~~~~~~
      * I got rid of the mysterious and horrible ClsInstInfo argument
        to tcInferApps, checkExpectedKindX, and various checkValid
        functions.  It was horrible!
      
      * I got rid of [Type] result of tcInferApps.  This list was used
        only in tcFamTyPats, when checking the LHS of a type instance;
        and if there is a cast in the middle, the list is meaningless.
        So I made tcInferApps simpler, and moved the complexity
        (not much) to tcInferApps.
      
        Result: tcInferApps is now pretty comprehensible again.
      
      * I refactored the many function in TcMType that instantiate skolems.
      
      Smaller things
      
      * I rejigged the error message in checkValidTelescope; I think it's
        quite a bit better now.
      
      * checkValidType was not rejecting constraints in a kind signature
           forall (a :: Eq b => blah). blah2
        That led to further errors when we then do an ambiguity check.
        So I make checkValidType reject it more aggressively.
      
      * I killed off quantifyConDecl, instead calling kindGeneralize
        directly.
      
      * I fixed an outright bug in tyCoVarsOfImplic, where we were not
        colleting the tyvar of the kind of the skolems
      
      * Renamed ClsInstInfo to AssocInstInfo, and made it into its
        own data type
      
      * Some fiddling around with pretty-printing of family
        instances which was trickier than I thought.  I wanted
        wildcards to print as plain "_" in user messages, although
        they each need a unique identity in the CoAxBranch.
      
      Some other oddments
      
      * Refactoring around the trace messages from reportUnsolved.
      * A bit of extra tc-tracing in TcHsSyn.commitFlexi
      
      This patch fixes a raft of bugs, and includes tests for them.
      
       * #14887
       * #15740
       * #15764
       * #15789
       * #15804
       * #15817
       * #15870
       * #15874
       * #15881
      2257a86d
  19. 17 Nov, 2018 1 commit
  20. 01 Nov, 2018 1 commit
    • Richard Eisenberg's avatar
      Don't lint erroneous programs. · 1f72a1c8
      Richard Eisenberg authored
      newFamInst lints its types. This is good. But it's not so good
      when there have been errors and thus recovery tycons are about.
      So we now don't.
      
      Fixes #15796.
      
      Test case: typecheck/should_fail/T15796
      1f72a1c8
  21. 25 Oct, 2018 1 commit
  22. 24 Oct, 2018 1 commit
    • Simon Peyton Jones's avatar
      Report a Wanted error even if there are Given ones · 6b1102e2
      Simon Peyton Jones authored
      We suppress some Given errors; see Note [Given errors]
      in TcErrors.  But we must be careful not to suppress
      Wanted errors because of the presence of these Given
      errors -- else we might allow compilation to bogusly
      proceed
      
      The rubber hits the road in TcRnTypes.insolubleCt,
      where we don't want to treat Givens as insoluble,
      nor (and this is the new bit) Deriveds that arise
      from Givens.  See Note [Given insolubles] in TcRnTypes.
      
      This fixes #15767.
      6b1102e2
  23. 15 Oct, 2018 1 commit
    • Ryan Scott's avatar
      Fix #12430 by expanding type synonyms in injTyVarsOfType · 26e81e90
      Ryan Scott authored
      We weren't expanding type synonyms when determining the
      injective type variables of a type, leading to certain non-injective
      families being mistakenly labeled as injective (#12430). Easily fixed
      with a tactical use of `coreView`.
      
      Test Plan: make test TEST=T12430
      
      Reviewers: bgamari, goldfire
      
      Reviewed By: goldfire
      
      Subscribers: goldfire, rwbarton, carter
      
      GHC Trac Issues: #12430
      
      Differential Revision: https://phabricator.haskell.org/D5228
      26e81e90
  24. 13 Sep, 2018 1 commit
  25. 02 Sep, 2018 1 commit
    • Ryan Scott's avatar
      Reject class instances with type families in kinds · 6dea7c16
      Ryan Scott authored
      Summary:
      GHC doesn't know how to handle type families that appear in
      class instances. Unfortunately, GHC didn't reject instances where
      type families appear in //kinds//, leading to #15515. This is easily
      rectified by calling `checkValidTypePat` on all arguments to a class
      in an instance (and not just the type arguments).
      
      Test Plan: make test TEST=T15515
      
      Reviewers: bgamari, goldfire, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: simonpj, rwbarton, carter
      
      GHC Trac Issues: #15515
      
      Differential Revision: https://phabricator.haskell.org/D5068
      6dea7c16
  26. 31 Aug, 2018 1 commit
    • Simon Peyton Jones's avatar
      Remove knot-tying bug in TcHsSyn.zonkTyVarOcc · 565ef4cc
      Simon Peyton Jones authored
      There was a subtle knot-tying bug in TcHsSyn.zonkTyVarOcc, revealed
      in Trac #15552.
      
      I fixed it by
      
      * Eliminating the short-circuiting optimisation in zonkTyVarOcc,
        instead adding a finite map to get sharing of zonked unification
        variables.
      
        See Note [Sharing when zonking to Type] in TcHsSyn
      
      * On the way I /added/ the short-circuiting optimisation to
        TcMType.zonkTcTyVar, which has no such problem.  This turned
        out (based on non-systematic measurements) to be a modest win.
      
        See Note [Sharing in zonking] in TcMType
      
      On the way I renamed some of the functions in TcHsSyn:
      
      * Ones ending in "X" (like zonkTcTypeToTypeX) take a ZonkEnv
      
      * Ones that do not end in "x" (like zonkTcTypeToType), don't.
        Instead they whiz up an empty ZonkEnv.
      565ef4cc
  27. 16 Aug, 2018 1 commit
    • Ryan Scott's avatar
      Fix #15527 by pretty-printing an RdrName prefixly · 5238f204
      Ryan Scott authored
      Summary:
      When `(.) @Int` is used without enabling `TypeApplications`,
      the resulting error message will pretty-print the (symbolic)
      `RdrName` `(.)`. However, it does so without parenthesizing it, which
      causes the pretty-printed expression to appear as `.@Int`. Yuck.
      
      Since the expression in a type application will always be prefix,
      we can fix this issue by using `pprPrefixOcc` instead of plain ol'
      `ppr`.
      
      Test Plan: make test TEST=T15527
      
      Reviewers: bgamari, monoidal, simonpj
      
      Reviewed By: monoidal, simonpj
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15527
      
      Differential Revision: https://phabricator.haskell.org/D5071
      5238f204
  28. 15 Aug, 2018 1 commit
  29. 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
  30. 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
  31. 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
  32. 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
  33. 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
  34. 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
  35. 13 May, 2018 1 commit