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. 06 Aug, 2018 1 commit
  2. 02 Aug, 2018 1 commit
    • Richard Eisenberg's avatar
      Remove decideKindGeneralisationPlan · c955a514
      Richard Eisenberg authored
      TypeInType came with a new function: decideKindGeneralisationPlan.
      This type-level counterpart to the term-level decideGeneralisationPlan
      chose whether or not a kind should be generalized. The thinking was
      that if `let` should not be generalized, then kinds shouldn't either
      (under the same circumstances around -XMonoLocalBinds).
      
      However, this is too conservative -- the situation described in the
      motivation for "let should be be generalized" does not occur in types.
      
      This commit thus removes decideKindGeneralisationPlan, always
      generalizing.
      
      One consequence is that tc_hs_sig_type_and_gen no longer calls
      solveEqualities, which reports all unsolved constraints, instead
      relying on the solveLocalEqualities in tcImplicitTKBndrs. An effect
      of this is that reporing kind errors gets delayed more frequently.
      This seems to be a net benefit in error reporting; often, alongside
      a kind error, the type error is now reported (and users might find
      type errors easier to understand).
      
      Some of these errors ended up at the top level, where it was
      discovered that the GlobalRdrEnv containing the definitions in the
      local module was not in the TcGblEnv, and thus errors were reported
      with qualified names unnecessarily. This commit rejiggers some of
      the logic around captureTopConstraints accordingly.
      
      One error message (typecheck/should_fail/T1633)
      is a regression, mentioning the name of a default method. However,
      that problem is already reported as #10087, its solution is far from
      clear, and so I'm not addressing it here.
      
      This commit fixes #15141. As it's an internal refactor, there is
      no concrete test case for it.
      
      Along the way, we no longer need the hsib_closed field of
      HsImplicitBndrs (it was used only in decideKindGeneralisationPlan)
      and so it's been removed, simplifying the datatype structure.
      
      Along the way, I removed code in the validity checker that looks
      at coercions. This isn't related to this patch, really (though
      it was, at one point), but it's an improvement, so I kept it.
      
      This updates the haddock submodule.
      c955a514
  3. 01 Aug, 2018 1 commit
    • Richard Eisenberg's avatar
      Remove the type-checking knot. · f8618a9b
      Richard Eisenberg authored
      Bug #15380 hangs because a knot-tied TyCon ended up in a kind.
      Looking at the code in tcInferApps, I'm amazed this hasn't happened
      before! I couldn't think of a good way to fix it (with dependent
      types, we can't really keep types out of kinds, after all), so
      I just went ahead and removed the knot.
      
      This was remarkably easy to do. In tcTyVar, when we find a TcTyCon,
      just use it. (Previously, we looked up the knot-tied TyCon and used
      that.) Then, during the final zonk, replace TcTyCons with the real,
      full-blooded TyCons in the global environment. It's all very easy.
      
      The new bit is explained in the existing
      Note [Type checking recursive type and class declarations]
      in TcTyClsDecls.
      
      Naturally, I removed various references to the knot and the
      zonkTcTypeInKnot (and related) functions. Now, we can print types
      during type checking with abandon!
      
      NB: There is a teensy error message regression with this patch,
      around the ordering of quantified type variables. This ordering
      problem is fixed (I believe) with the patch for #14880. The ordering
      affects only internal variables that cannot be instantiated with
      any kind of visible type application.
      
      There is also a teensy regression around the printing of types
      in TH splices. I think this is really a TH bug and will file
      separately.
      
      Test case: dependent/should_fail/T15380
      f8618a9b
  4. 27 Jul, 2018 1 commit
  5. 25 Jul, 2018 2 commits
    • Simon Peyton Jones's avatar
      Treat isConstraintKind more consistently · c5d31df7
      Simon Peyton Jones authored
      It turned out that we were not being consistent
      about our use of isConstraintKind.
      
      It's delicate, because the typechecker treats Constraint and Type as
      /distinct/, whereas they are the /same/ in the rest of the compiler
      (Trac #11715).
      
      And had it wrong, which led to Trac #15412.  This patch does the
      following:
      
      * Rename isConstraintKind      to tcIsConstraintKind
               returnsConstraintKind to tcReturnsConstraintKind
        to emphasise that they use the 'tcView' view of types.
      
      * Move these functions, and some related ones (tcIsLiftedTypeKind),
        from Kind.hs, to group together in Type.hs, alongside isPredTy.
      
      It feels very unsatisfactory that these 'tcX' functions live in Type,
      but it happens because isPredTy is called later in the compiler
      too.  But it's a consequence of the 'Constraint vs Type' dilemma.
      c5d31df7
    • 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
  6. 24 Jul, 2018 2 commits
    • Matthías Páll Gissurarson's avatar
      Clone relevant constraints to avoid side-effects on HoleDests. Fixes #15370. · 0dc86f6b
      Matthías Páll Gissurarson authored
      Summary: When looking for valid hole fits, the constraints relevant
      to the hole may sometimes contain a HoleDest. Previously,
      these were not cloned, which could cause the filling of filled
      coercion hole being, which would cause an assert to fail. This is now fixed.
      
      Test Plan: Regression test included.
      
      Reviewers: simonpj, bgamari, goldfire
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #15370
      
      Differential Revision: https://phabricator.haskell.org/D5004
      0dc86f6b
    • Simon Peyton Jones's avatar
      Fix a nasty bug in piResultTys · e1b5a117
      Simon Peyton Jones authored
      I was failing to instantiate vigorously enough in Type.piResultTys
      and in the very similar function ToIface.toIfaceAppArgsX
      
      This caused Trac #15428.  The fix is easy.
      
      See Note [Care with kind instantiation] in Type.hs
      e1b5a117
  7. 23 Jul, 2018 1 commit
    • Simon Peyton Jones's avatar
      Stop marking soluble ~R# constraints as insoluble · f0d27f51
      Simon Peyton Jones authored
      We had a constraint (a b ~R# Int), and were marking it as 'insoluble'.
      That's bad; it isn't.  And it caused Trac #15431. Soultion is simple.
      
      I did a tiny refactor on can_eq_app, so that it is used only for
      nominal equalities.
      f0d27f51
  8. 20 Jul, 2018 1 commit
    • Ryan Scott's avatar
      Fix #15423 by using pprAStmtContext · 99f45e2a
      Ryan Scott authored
      Summary:
      Previously, we were using `pprStmtContext` instead, which
      led to error messages missing indefinite articles where they were
      required.
      
      Test Plan: make test TEST="T13242a T7786 Typeable1"
      
      Reviewers: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #15423
      
      Differential Revision: https://phabricator.haskell.org/D4992
      99f45e2a
  9. 16 Jul, 2018 1 commit
    • Vladislav Zavialov's avatar
      Do not imply NoStarIsType by TypeOperators/TypeInType · 65c186f0
      Vladislav Zavialov authored
      Implementation of the "Embrace TypeInType" proposal was done according
      to the spec, which specified that TypeOperators must imply NoStarIsType.
      This implication was meant to prevent breakage and to be removed in 2
      releases.  However, compiling head.hackage has shown that this
      implication only magnified the breakage, so there is no reason to have
      it in the first place.
      
      To remain in compliance with the three-release policy, we add a
      workaround to define the (*) type operator even when -XStarIsType is on.
      
      Test Plan: ./validate
      
      Reviewers: bgamari, RyanGlScott, goldfire, phadej, hvr
      
      Reviewed By: bgamari, RyanGlScott
      
      Subscribers: harpocrates, rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4865
      65c186f0
  10. 15 Jul, 2018 1 commit
  11. 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
  12. 10 Jul, 2018 2 commits
    • Richard Eisenberg's avatar
      Unwrap casts before checking vars in eager unifier · 042df603
      Richard Eisenberg authored
      Previously, checking whether (tv |> co) ~ (tv |> co) got deferred,
      because we looked for vars before stripping casts. (The left type
      would get stripped, and then tv ~ (tv |> co) would scare the occurs-
      checker.)
      
      This opportunity for improvement presented itself in other work.
      This is just an optimization. Some programs can now report more
      errors simultaneously.
      042df603
    • Simon Peyton Jones's avatar
      More refactoring in TcValidity · fd0f0334
      Simon Peyton Jones authored
      This patch responds to Trac #15334 by making it an error to
      write an instance declaration for a tuple constraint like
      (Eq [a], Show [a]).
      
      I then discovered that instance validity checking was
      scattered betweeen TcInstDcls and TcValidity, so I took
      the time to bring it all together, into
        TcValidity.checkValidInstHead
      
      In doing so I discovered that there are lot of special
      cases.   I have not changed them, but at least they are
      all laid out clearly now.
      fd0f0334
  13. 06 Jul, 2018 1 commit
  14. 05 Jul, 2018 3 commits
    • Ryan Scott's avatar
      Accept new stdout for tcrun045 · 45f00268
      Ryan Scott authored
      The stdout produced by test tcrun045 changed in commit
      45f44e2c. The change appears to be
      benign, so I've decided to accept it.
      45f00268
    • Ryan Scott's avatar
      Fix #15308 by suppressing invisble args more rigorously · 93b7ac8d
      Ryan Scott authored
      Summary:
      There was a buglet in `stripInvisArgs` (which is part of the
      pretty-printing pipeline for types) in which only invisble arguments
      which came before any visible arguments would be suppressed, but any
      invisble arguments that came //after// visible ones would still be
      printed, even if `-fprint-explicit-kinds`  wasn't enabled.
      The fix is simple: make `stripInvisArgs` recursively process the
      remaining types even after a visible argument is encountered.
      
      Test Plan: make test TEST=T15308
      
      Reviewers: goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: simonpj, rwbarton, thomie, carter
      
      GHC Trac Issues: #15308
      
      Differential Revision: https://phabricator.haskell.org/D4891
      93b7ac8d
    • Simon Peyton Jones's avatar
      Refactor validity checking for constraints · 45f44e2c
      Simon Peyton Jones authored
      There are several changes here.
      
      * TcInteract has gotten too big, so I moved all the class-instance
        matching out of TcInteract into a new module ClsInst. It parallels
        the FamInst module.
      
        The main export of ClsInst is matchGlobalInst.
        This now works in TcM not TcS.
      
      * A big reason to make matchGlobalInst work in TcM is that we can
        then use it from TcValidity.checkSimplifiableClassConstraint.
        That extends checkSimplifiableClassConstraint to work uniformly
        for built-in instances, which means that we now get a warning
        if we have givens (Typeable x, KnownNat n); see Trac #15322.
      
      * This change also made me refactor LookupInstResult, in particular
        by adding the InstanceWhat field.  I also changed the name of the
        type to ClsInstResult.
      
        Then instead of matchGlobalInst reporting a staging error (which is
        inappropriate for the call from TcValidity), we can do so in
        TcInteract.checkInstanceOK.
      
      * In TcValidity, we now check quantified constraints for termination.
        For example, this signature should be rejected:
           f :: (forall a. Eq (m a) => Eq (m a)) => blah
        as discussed in Trac #15316.   The main change here is that
        TcValidity.check_pred_help now uses classifyPredType, and has a
        case for ForAllPred which it didn't before.
      
        This had knock-on refactoring effects in TcValidity.
      45f44e2c
  15. 22 Jun, 2018 1 commit
    • Simon Peyton Jones's avatar
      Instances in no-evidence implications · 32eb4199
      Simon Peyton Jones authored
      Trac #15290 showed that it's possible that we might attempt to use a
      quantified constraint to solve an equality in a situation where we
      don't have anywhere to put the evidence bindings.  This made GHC crash.
      
      This patch stops the crash, but still rejects the pogram.  See
      Note [Instances in no-evidence implications] in TcInteract.
      
      Finding this bug revealed another lurking bug:
      
      * An infelicity in the treatment of superclasses -- we were expanding
        them locally at the leaves, rather than at their binding site; see
        (3a) in Note [The superclass story].
      
        As a consequence, TcRnTypes.superclassesMightHelp must look inside
        implications.
      
      In more detail:
      
      * Stop the crash, by making TcInteract.chooseInstance test for
        the no-evidence-bindings case.  In that case we simply don't
        use the instance.  This entailed a slight change to the type
        of chooseInstance.
      
      * Make TcSMonad.getPendingScDicts (now renamed getPendingGivenScs)
        return only Givens from the /current level/; and make
        TcRnTypes.superClassesMightHelp look inside implications.
      
      * Refactor the simpl_loop and superclass-expansion stuff in
        TcSimplify.  The logic is much easier to understand now, and
        has less duplication.
      32eb4199
  16. 20 Jun, 2018 1 commit
  17. 18 Jun, 2018 1 commit
  18. 16 Jun, 2018 2 commits
  19. 15 Jun, 2018 3 commits
    • Sylvain Henry's avatar
      Built-in Natural literals in Core · fe770c21
      Sylvain Henry authored
      Add support for built-in Natural literals in Core.
      
      - Replace MachInt,MachWord, LitInteger, etc. with a single LitNumber
        constructor with a LitNumType field
      - Support built-in Natural literals
      - Add desugar warning for negative literals
      - Move Maybe(..) from GHC.Base to GHC.Maybe for module dependency
        reasons
      
      This patch introduces only a few rules for Natural literals (compared
      to Integer's rules). Factorization of the built-in rules for numeric
      literals will be done in another patch as this one is already big to
      review.
      
      Test Plan:
        validate
        test build with integer-simple
      
      Reviewers: hvr, bgamari, goldfire, Bodigrim, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: phadej, simonpj, RyanGlScott, carter, hsyl20, rwbarton,
      thomie
      
      GHC Trac Issues: #14170, #14465
      
      Differential Revision: https://phabricator.haskell.org/D4212
      fe770c21
    • Kirill Zaborsky's avatar
      Fix #13833: accept type literals with no FlexibleInstances · 42f3b53b
      Kirill Zaborsky authored
      Test Plan: ./validate
      
      Reviewers: bgamari, simonpj
      
      Reviewed By: bgamari, simonpj
      
      Subscribers: simonpj, rwbarton, thomie, carter
      
      GHC Trac Issues: #13833
      
      Differential Revision: https://phabricator.haskell.org/D4823
      42f3b53b
    • Tao He's avatar
      Add "quantified constraint" context in error message, fix #15231. · 91822e4e
      Tao He authored
      This patch adds "quantified constraint" context in error message when
      UndecidableInstances checking fails for quantified constraints.
      See Trac #15231:comment#1.
      
      This patch also pretty-prints the instance head for better error messages.
      
      Test Plan: make test TEST="T15231"
      
      Reviewers: bgamari, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: simonpj, rwbarton, thomie, carter
      
      GHC Trac Issues: #15231
      
      Differential Revision: https://phabricator.haskell.org/D4819
      91822e4e
  20. 14 Jun, 2018 2 commits
    • 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
    • Ninjatrappeur's avatar
      Make Control.Exception.throw levity polymorphic. · 8ae7c1b5
      Ninjatrappeur authored
      Test Plan: Validate.
      
      Reviewers: hvr, bgamari, sighingnow
      
      Reviewed By: sighingnow
      
      Subscribers: tdammers, sighingnow, rwbarton, thomie, carter
      
      GHC Trac Issues: #15180
      
      Differential Revision: https://phabricator.haskell.org/D4827
      8ae7c1b5
  21. 08 Jun, 2018 2 commits
  22. 07 Jun, 2018 4 commits
    • Ryan Scott's avatar
      Fix #15236 by removing parentheses from funTyConName · 3397396a
      Ryan Scott authored
      Currently, `funTyConName` is defined as:
      
      ```lang=haskell
      funTyConName = mkPrimTyConName (fsLit "(->)") funTyConKey funTyCon
      ```
      
      What's strange about this definition is that there are extraneous
      parentheses around `->`, which is quite unlike every other infix
      `Name`. As a result, the `:info (->)` output is totally garbled (see
      Trac #15236).
      
      It's quite straightforward to fix that particular bug by removing the
      extraneous parentheses. However, it turns out that this makes some
      test output involving `Show` instances for `TypeRep` look less
      appealing, since `->` is no longer surrounded with parentheses when
      applied prefix. But neither were any /other/ infix type constructors!
      The right fix there was to change `showTypeable` to put parentheses
      around prefix applications of infix tycons.
      
      Test Plan: ./validate
      
      Reviewers: bgamari, hvr
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #15236
      
      Differential Revision: https://phabricator.haskell.org/D4799
      3397396a
    • Ben Gamari's avatar
      testsuite: Skip T13838 in ghci way · 04e29fc6
      Ben Gamari authored
      Test Plan: `make slowtest TEST=T13838`
      
      Reviewers: alpmestan, dfeuer
      
      Reviewed By: dfeuer
      
      Subscribers: dfeuer, rwbarton, thomie, carter
      
      GHC Trac Issues: #15238
      
      Differential Revision: https://phabricator.haskell.org/D4802
      04e29fc6
    • Ben Gamari's avatar
      testsuite: Add test for #15232 · 5026840f
      Ben Gamari authored
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #15232
      
      Differential Revision: https://phabricator.haskell.org/D4807
      5026840f
    • Andreas Herrmann's avatar
      Fix unparseable pretty-printing of promoted data cons · 767536cc
      Andreas Herrmann authored
      Previously we would print code which would not round-trip:
      ```
      > :set -XDataKinds
      > :set -XPolyKinds
      > data Proxy k = Proxy
      > _ :: Proxy '[ 'True ]
      error:
        Found hole: _ :: Proxy '['True]
      > _ :: Proxy '['True]
      error:
          Invalid type signature: _ :: ...
          Should be of form <variable> :: <type>
      ```
      
      Test Plan: Validate with T14343
      
      Reviewers: RyanGlScott, goldfire, bgamari, tdammers
      
      Reviewed By: RyanGlScott, bgamari
      
      Subscribers: tdammers, rwbarton, thomie, carter
      
      GHC Trac Issues: #14343
      
      Differential Revision: https://phabricator.haskell.org/D4746
      767536cc
  23. 04 Jun, 2018 1 commit
    • Simon Peyton Jones's avatar
      Implement QuantifiedConstraints · 7df58960
      Simon Peyton Jones authored
      We have wanted quantified constraints for ages and, as I hoped,
      they proved remarkably simple to implement.   All the machinery was
      already in place.
      
      The main ticket is Trac #2893, but also relevant are
        #5927
        #8516
        #9123 (especially!  higher kinded roles)
        #14070
        #14317
      
      The wiki page is
        https://ghc.haskell.org/trac/ghc/wiki/QuantifiedConstraints
      which in turn contains a link to the GHC Proposal where the change
      is specified.
      
      Here is the relevant Note:
      
      Note [Quantified constraints]
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      The -XQuantifiedConstraints extension allows type-class contexts like
      this:
      
        data Rose f x = Rose x (f (Rose f x))
      
        instance (Eq a, forall b. Eq b => Eq (f b))
              => Eq (Rose f a)  where
          (Rose x1 rs1) == (Rose x2 rs2) = x1==x2 && rs1 >= rs2
      
      Note the (forall b. Eq b => Eq (f b)) in the instance contexts.
      This quantified constraint is needed to solve the
       [W] (Eq (f (Rose f x)))
      constraint which arises form the (==) definition.
      
      Here are the moving parts
        * Language extension {-# LANGUAGE QuantifiedConstraints #-}
          and add it to ghc-boot-th:GHC.LanguageExtensions.Type.Extension
      
        * A new form of evidence, EvDFun, that is used to discharge
          such wanted constraints
      
        * checkValidType gets some changes to accept forall-constraints
          only in the right places.
      
        * Type.PredTree gets a new constructor ForAllPred, and
          and classifyPredType analyses a PredType to decompose
          the new forall-constraints
      
        * Define a type TcRnTypes.QCInst, which holds a given
          quantified constraint in the inert set
      
        * TcSMonad.InertCans gets an extra field, inert_insts :: [QCInst],
          which holds all the Given forall-constraints.  In effect,
          such Given constraints are like local instance decls.
      
        * When trying to solve a class constraint, via
          TcInteract.matchInstEnv, use the InstEnv from inert_insts
          so that we include the local Given forall-constraints
          in the lookup.  (See TcSMonad.getInstEnvs.)
      
        * topReactionsStage calls doTopReactOther for CIrredCan and
          CTyEqCan, so they can try to react with any given
          quantified constraints (TcInteract.matchLocalInst)
      
        * TcCanonical.canForAll deals with solving a
          forall-constraint.  See
             Note [Solving a Wanted forall-constraint]
             Note [Solving a Wanted forall-constraint]
      
        * We augment the kick-out code to kick out an inert
          forall constraint if it can be rewritten by a new
          type equality; see TcSMonad.kick_out_rewritable
      
      Some other related refactoring
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      * Move SCC on evidence bindings to post-desugaring, which fixed
        #14735, and is generally nicer anyway because we can use
        existing CoreSyn free-var functions.  (Quantified constraints
        made the free-vars of an ev-term a bit more complicated.)
      
      * In LookupInstResult, replace GenInst with OneInst and NotSure,
        using the latter for multiple matches and/or one or more
        unifiers
      7df58960
  24. 03 Jun, 2018 2 commits
    • 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
    • Ryan Scott's avatar
      Fix #13777 by improving the underdetermined CUSK error message · ac91d073
      Ryan Scott authored
      The error message that GHC emits from underdetermined CUSKs
      is rather poor, since:
      
      1. It may print an empty list of user-written variables if there
          are none in the declaration.
      2. It may not mention any `forall`-bound, underdetermined
          variables in the result kind.
      
      To resolve these issues, this patch:
      
      1. Doesn't bother printing a herald about user-written
          variables if there are none.
      2. Prints the result kind to advertise any
          underdetermination it may exhibit.
      
      Test Plan: make test TEST=T13777
      
      Reviewers: goldfire, bgamari
      
      Reviewed By: goldfire
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #13777
      
      Differential Revision: https://phabricator.haskell.org/D4771
      ac91d073
  25. 30 May, 2018 2 commits
    • Matthías Páll Gissurarson's avatar
      Improved Valid Hole Fits · e0b44e2e
      Matthías Páll Gissurarson authored
      I've changed the name from `Valid substitutions` to `Valid hole fits`,
      since "substitution" already has a well defined meaning within the
      theory. As part of this change, the flags and output is reanamed, with
      substitution turning into hole-fit in most cases. "hole fit" was already
      used internally in the code, it's clear and shouldn't cause any
      confusion.
      
      In this update, I've also reworked how we manage side-effects in the
      hole we are considering.
      
      This allows us to consider local bindings such as where clauses and
      arguments to functions, suggesting e.g. `a` for `head (x:xs) where head
      :: [a] -> a`.
      
      It also allows us to find suggestions such as `maximum` for holes of
      type `Ord a => a -> [a]`, and `max` when looking for a match for the
      hole in `g = foldl1 _`, where `g :: Ord a => [a] -> a`.
      
      We also show much improved output for refinement hole fits, and
      fixes #14990. We now show the correct type of the function, but we also
      now show what the arguments to the function should be e.g. `foldl1 (_ ::
      Integer -> Integer -> Integer)` when looking for `[Integer] -> Integer`.
      
      I've moved the bulk of the code from `TcErrors.hs` to a new file,
      `TcHoleErrors.hs`, since it was getting too big to not live on it's own.
      
      This addresses the considerations raised in #14969, and takes proper
      care to set the `tcLevel` of the variables to the right level before
      passing it to the simplifier.
      
      We now also zonk the suggestions properly, which improves the output of
      the refinement hole fits considerably.
      
      This also filters out suggestions from the `GHC.Err` module, since even
      though `error` and `undefined` are indeed valid hole fits, they are
      "trivial", and almost never useful to the user.
      
      We now find the hole fits using the proper manner, namely by solving
      nested implications. This entails that the givens are passed along using
      the implications the hole was nested in, which in turn should mean that
      there will be fewer weird bugs in the typed holes.
      
      I've also added a new sorting method (as suggested by SPJ) and sort by
      the size of the types needed to turn the hole fits into the type of the
      hole. This gives a reasonable approximation to relevance, and is much
      faster than the subsumption check. I've also added a flag to toggle
      whether to use this new sorting algorithm (as is done by default) or the
      subsumption algorithm. This fixes #14969
      
      I've also added documentation for these new flags and update the
      documentation according to the new output.
      
      Reviewers: bgamari, goldfire
      
      Reviewed By: bgamari
      
      Subscribers: simonpj, rwbarton, thomie, carter
      
      GHC Trac Issues: #14969, #14990, #10946
      
      Differential Revision: https://phabricator.haskell.org/D4444
      e0b44e2e
    • Tao He's avatar
      Put the `ev_binds` of main function inside `runMainIO` · 49e423e9
      Tao He authored
      This ensures that the deferred type error can be emitted correctly.
      
      For `main` function in `Main` module, we have
      
          :Main.main = GHC.TopHandler.runMainIO main
      
      When the type of `main` is not `IO t` and the
      `-fdefer-type-errors` is enabled, the `ev_binds`
      of `main` function will contain deferred type
      errors.
      
      Previously, the `ev_binds` are bound to `runMainIO main`,
      rather than `main`, the type error exception at runtime
      cannot be handled properly. See Trac #13838.
      
      This patch fix that.
      
      Test Plan: make test TEST="T13838"
      
      Reviewers: bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #13838
      
      Differential Revision: https://phabricator.haskell.org/D4708
      49e423e9