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 Apr, 2017 2 commits
    • Simon Peyton Jones's avatar
      Add a missing addDeferredBinding · 2f9f1f86
      Simon Peyton Jones authored
      I'd forgotten to add deferred bindings for user type
      errors.  Fixes Trac #13487.
      2f9f1f86
    • Simon Peyton Jones's avatar
      Don't report fundep wanted/wanted errors · 48daaaf0
      Simon Peyton Jones authored
      This makes GHC drop derived FunDep errors when they
      are come from wanted/wanted interactions.  Much along
      the lines of "don't rewrite wanteds with wanteds".
      
      See TcRnTypes Note [Dropping derived constraints]
      and the new code in isDroppableDerivedLoc.
      
      Fixes Trac #13506.
      48daaaf0
  2. 27 Mar, 2017 1 commit
    • Simon Peyton Jones's avatar
      Fix error-message suppress on given equalities · e0ad55f8
      Simon Peyton Jones authored
      I'd got the logic slightly wrong when reporting type errors
      for insoluble 'given' equalities.  We suppress insoluble givens
      under some circumstances (see Note [Given errors]), but we then
      suppressed subsequent 'wanted' errors because the (suppressed)
      'given' error "won".  Result: no errors at all :-(.
      
      This patch fixes it and
       - Renames TcType.isTyVarUnderDatatype to the more
         perspicuous TcType.isInsolubleOccursCheck
      
      In doing this I realise that I don't understand why we need
      to keep the insolubles partitioned out separately at all...
      but that is for another day.
      e0ad55f8
  3. 17 Mar, 2017 1 commit
    • Richard Eisenberg's avatar
      Fix #12709 by not building bad applications · dca44adb
      Richard Eisenberg authored
      In an effort to report multiple levity polymorphism errors all at
      once, the desugarer does not fail when encountering bad levity
      polymorphism. But we must be careful not to build the bad applications,
      lest they try to satisfy the let/app invariant and call
      isUnliftedType on a levity polymorphic type. This protects calls
      to mkCoreAppDs appropriately.
      
      test case: typecheck/should_fail/T12709
      dca44adb
  4. 02 Mar, 2017 1 commit
  5. 26 Feb, 2017 1 commit
    • rwbarton's avatar
      tests: remove extra_files.py (#12223) · 3415bcaa
      rwbarton authored and Ben Gamari's avatar Ben Gamari committed
      The script I used is included as testsuite/driver/kill_extra_files.py,
      though at this point it is for mostly historical interest.
      
      Some of the tests in libraries/hpc relied on extra_files.py, so this
      commit includes an update to that submodule.
      
      One test in libraries/process also relies on extra_files.py, but we
      cannot update that submodule so easily, so for now we special-case it
      in the test driver.
      3415bcaa
  6. 21 Feb, 2017 2 commits
  7. 30 Jan, 2017 1 commit
    • Ryan Scott's avatar
      Check that a default type signature aligns with the non-default signature · 7363d538
      Ryan Scott authored and Ben Gamari's avatar Ben Gamari committed
      Before, GHC was extremely permissive about the form a default type
      signature could take on in a class declaration. Notably, it would accept
      garbage like this:
      
        class Monad m => MonadSupply m where
          fresh :: m Integer
          default fresh :: MonadTrans t => t m Integer
          fresh = lift fresh
      
      And then give an extremely confusing error message when you actually
      tried to declare an empty instance of MonadSupply. We now do extra
      validity checking of default type signatures to ensure that they align
      with their non-default type signature counterparts. That is, a default
      type signature is allowed to differ from the non-default one only in its
      context - they must otherwise be alpha-equivalent.
      
      Fixes #12918.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, simonpj, austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: mpickering, dfeuer, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2983
      
      GHC Trac Issues: #12918
      7363d538
  8. 22 Jan, 2017 2 commits
  9. 19 Jan, 2017 1 commit
    • Richard Eisenberg's avatar
      Update levity polymorphism · e7985ed2
      Richard Eisenberg authored
      This commit implements the proposal in
      https://github.com/ghc-proposals/ghc-proposals/pull/29 and
      https://github.com/ghc-proposals/ghc-proposals/pull/35.
      
      Here are some of the pieces of that proposal:
      
      * Some of RuntimeRep's constructors have been shortened.
      
      * TupleRep and SumRep are now parameterized over a list of RuntimeReps.
      * This
      means that two types with the same kind surely have the same
      representation.
      Previously, all unboxed tuples had the same kind, and thus the fact
      above was
      false.
      
      * RepType.typePrimRep and friends now return a *list* of PrimReps. These
      functions can now work successfully on unboxed tuples. This change is
      necessary because we allow abstraction over unboxed tuple types and so
      cannot
      always handle unboxed tuples specially as we did before.
      
      * We sometimes have to create an Id from a PrimRep. I thus split PtrRep
      * into
      LiftedRep and UnliftedRep, so that the created Ids have the right
      strictness.
      
      * The RepType.RepType type was removed, as it didn't seem to help with
      * much.
      
      * The RepType.repType function is also removed, in favor of typePrimRep.
      
      * I have waffled a good deal on whether or not to keep VoidRep in
      TyCon.PrimRep. In the end, I decided to keep it there. PrimRep is *not*
      represented in RuntimeRep, and typePrimRep will never return a list
      including
      VoidRep. But it's handy to have in, e.g., ByteCodeGen and friends. I can
      imagine another design choice where we have a PrimRepV type that is
      PrimRep
      with an extra constructor. That seemed to be a heavier design, though,
      and I'm
      not sure what the benefit would be.
      
      * The last, unused vestiges of # (unliftedTypeKind) have been removed.
      
      * There were several pretty-printing bugs that this change exposed;
      * these are fixed.
      
      * We previously checked for levity polymorphism in the types of binders.
      * But we
      also must exclude levity polymorphism in function arguments. This is
      hard to check
      for, requiring a good deal of care in the desugarer. See Note [Levity
      polymorphism
      checking] in DsMonad.
      
      * In order to efficiently check for levity polymorphism in functions, it
      * was necessary
      to add a new bit of IdInfo. See Note [Levity info] in IdInfo.
      
      * It is now safe for unlifted types to be unsaturated in Core. Core Lint
      * is updated
      accordingly.
      
      * We can only know strictness after zonking, so several checks around
      * strictness
      in the type-checker (checkStrictBinds, the check for unlifted variables
      under a ~
      pattern) have been moved to the desugarer.
      
      * Along the way, I improved the treatment of unlifted vs. banged
      * bindings. See
      Note [Strict binds checks] in DsBinds and #13075.
      
      * Now that we print type-checked source, we must be careful to print
      * ConLikes correctly.
      This is facilitated by a new HsConLikeOut constructor to HsExpr.
      Particularly troublesome
      are unlifted pattern synonyms that get an extra void# argument.
      
      * Includes a submodule update for haddock, getting rid of #.
      
      * New testcases:
        typecheck/should_fail/StrictBinds
        typecheck/should_fail/T12973
        typecheck/should_run/StrictPats
        typecheck/should_run/T12809
        typecheck/should_fail/T13105
        patsyn/should_fail/UnliftedPSBind
        typecheck/should_fail/LevPolyBounded
        typecheck/should_compile/T12987
        typecheck/should_compile/T11736
      
      * Fixed tickets:
        #12809
        #12973
        #11736
        #13075
        #12987
      
      * This also adds a test case for #13105. This test case is
      * "compile_fail" and
      succeeds, because I want the testsuite to monitor the error message.
      When #13105 is fixed, the test case will compile cleanly.
      e7985ed2
  10. 12 Jan, 2017 1 commit
    • Simon Peyton Jones's avatar
      Fix top-level constraint handling (Trac #12921) · f5f6d423
      Simon Peyton Jones authored
      Some out-of-scope errors were not being reported if anyone
      throws an un-caught exception in the TcM monad.  That led to
      
        ghc: panic! (the 'impossible' happened)
      	initTc: unsolved constraints
      
      I fixed this
      
      * Splitting captureConstraints to use an auxilliary
        tryCaptureConstraints (which never fails)
      
      * Define a new TcSimplify.captureTopConstraints (replacing
        the old TcRnMonad.captureTopConstraints), which reports
        any unsolved out-of-scope constraints before propagating
        the exception
      
      That in turn allowed me to do some tidying up of the static-constraint
      machinery, reducing duplication.
      
      Also solves #13106.
      f5f6d423
  11. 02 Jan, 2017 1 commit
  12. 18 Dec, 2016 1 commit
  13. 15 Dec, 2016 1 commit
  14. 25 Nov, 2016 1 commit
    • Simon Peyton Jones's avatar
      Another major constraint-solver refactoring · 1eec1f21
      Simon Peyton Jones authored
      This patch takes further my refactoring of the constraint
      solver, which I've been doing over the last couple of months
      in consultation with Richard.
      
      It fixes a number of tricky bugs that made the constraint
      solver actually go into a loop, including
      
        Trac #12526
        Trac #12444
        Trac #12538
      
      The main changes are these
      
      * Flatten unification variables (fmvs/fuvs) appear on the LHS
        of a tvar/tyvar equality; thus
                 fmv ~ alpha
        and not
                 alpha ~ fmv
      
        See Note [Put flatten unification variables on the left]
        in TcUnify.  This is implemented by TcUnify.swapOverTyVars.
      
      * Don't reduce a "loopy" CFunEqCan where the fsk appears on
        the LHS:
            F t1 .. tn ~ fsk
        where 'fsk' is free in t1..tn.
        See Note [FunEq occurs-check principle] in TcInteract
      
        This neatly stops some infinite loops that people reported;
        and it allows us to delete some crufty code in reduce_top_fun_eq.
        And it appears to be no loss whatsoever.
      
        As well as fixing loops, ContextStack2 and T5837 both terminate
        when they didn't before.
      
      * Previously we generated "derived shadow" constraints from
        Wanteds, but we could (and sometimes did; Trac #xxxx) repeatedly
        generate a derived shadow from the same Wanted.
      
        A big change in this patch is to have two kinds of Wanteds:
           [WD] behaves like a pair of a Wanted and a Derived
           [W]  behaves like a Wanted only
        See CtFlavour and ShadowInfo in TcRnTypes, and the ctev_nosh
        field of a Wanted.
      
        This turned out to be a lot simpler.  A [WD] gets split into a
        [W] and a [D] in TcSMonad.maybeEmitShaodow.
      
        See TcSMonad Note [The improvement story and derived shadows]
      
      * Rather than have a separate inert_model in the InertCans, I've
        put the derived equalities back into inert_eqs.  We weren't
        gaining anything from a separate field.
      
      * Previously we had a mode for the constraint solver in which it
        would more aggressively solve Derived constraints; it was used
        for simplifying the context of a 'deriving' clause, or a 'default'
        delcaration, for example.
      
        But the complexity wasn't worth it; now I just make proper Wanted
        constraints.  See TcMType.cloneWC
      
      * Don't generate injectivity improvement for Givens; see
        Note [No FunEq improvement for Givens] in TcInteract
      
      * solveSimpleWanteds leaves the insolubles in-place rather than
        returning them.  Simpler.
      
      I also did lots of work on comments, including fixing Trac #12821.
      1eec1f21
  15. 17 Nov, 2016 1 commit
    • Edward Z. Yang's avatar
      Test for type synonym loops on TyCon. · 31398fbc
      Edward Z. Yang authored
      
      
      Summary:
      Previously, we tested for type synonym loops by doing
      a syntactic test on the literal type synonym declarations.
      However, in some cases, loops could go through hs-boot
      files, leading to an infinite loop (#12042); a similar
      situation can occur when signature merging.
      
      This commit replaces the syntactic test with a test on
      TyCon, simply by walking down all type synonyms until
      we bottom out, or find we've looped back.  It's a lot
      simpler.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, austin, bgamari
      
      Subscribers: goldfire, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2656
      
      GHC Trac Issues: #12042
      31398fbc
  16. 04 Nov, 2016 1 commit
  17. 21 Oct, 2016 1 commit
    • Simon Peyton Jones's avatar
      A collection of type-inference refactorings. · 3f5673f3
      Simon Peyton Jones authored
      This patch does a raft of useful tidy-ups in the type checker.
      I've been meaning to do this for some time, and finally made
      time to do it en route to ICFP.
      
      1. Modify TcType.ExpType to make a distinct data type,
         InferResult for the Infer case, and consequential
         refactoring.
      
      2. Define a new function TcUnify.fillInferResult, to fill in
         an InferResult. It uses TcMType.promoteTcType to promote
         the type to the level of the InferResult.
         See TcMType Note [Promoting a type]
         This refactoring is in preparation for an improvement
         to typechecking pattern bindings, coming next.
      
         I flirted with an elaborate scheme to give better
         higher rank inference, but it was just too complicated.
         See TcMType Note [Promotion and higher rank types]
      
      3. Add to InferResult a new field ir_inst :: Bool to say
         whether or not the type used to fill in the
         InferResult should be deeply instantiated.  See
         TcUnify Note [Deep instantiation of InferResult].
      
      4. Add a TcLevel to SkolemTvs. This will be useful generally
      
          - it's a fast way to see if the type
            variable escapes when floating (not used yet)
      
          - it provides a good consistency check when updating a
            unification variable (TcMType.writeMetaTyVarRef, the
            level_check_ok check)
      
         I originally had another reason (related to the flirting
         in (2), but I left it in because it seems like a step in
         the right direction.
      
      5. Reduce and simplify the plethora of uExpType,
         tcSubType and related functions in TcUnify.  It was
         such an opaque mess and it's still not great, but it's
         better.
      
      6. Simplify the uo_expected field of TypeEqOrigin.  Richard
         had generatlised it to a ExpType, but it was almost always
         a Check type.  Now it's back to being a plain TcType which
         is much, much easier.
      
      7. Improve error messages by refraining from skolemisation when
         it's clear that there's an error: see
         TcUnify Note [Don't skolemise unnecessarily]
      
      8. Type.isPiTy and isForAllTy seem to be missing a coreView check,
         so I added it
      
      9. Kill off tcs_used_tcvs.  Its purpose is to track the
         givens used by wanted constraints.  For dictionaries etc
         we do that via the free vars of the /bindings/ in the
         implication constraint ic_binds.  But for coercions we
         just do update-in-place in the type, rather than
         generating a binding.  So we need something analogous to
         bindings, to track what coercions we have added.
      
         That was the purpose of tcs_used_tcvs.  But it only
         worked for a /single/ iteration, whereas we may have
         multiple iterations of solving an implication.  Look
         at (the old) 'setImplicationStatus'.  If the constraint
         is unsolved, it just drops the used_tvs on the floor.
         If it becomes solved next time round, we'll pick up
         coercions used in that round, but ignore ones used in
         the first round.
      
         There was an outright bug.  Result = (potentialy) bogus
         unused-constraint errors.  Constructing a case where this
         actually happens seems quite trick so I did not do so.
      
         Solution: expand EvBindsVar to include the (free vars of
         the) coercions, so that the coercions are tracked in
         essentially the same way as the bindings.
      
         This turned out to be much simpler.  Less code, more
         correct.
      
      10. Make the ic_binds field in an implication have type
            ic_binds :: EvBindsVar
          instead of (as previously)
             ic_binds :: Maybe EvBindsVar
          This is notably simpler, and faster to use -- less
          testing of the Maybe.  But in the occaional situation
          where we don't have anywhere to put the bindings, the
          belt-and-braces error check is lost.  So I put it back
          as an ASSERT in 'setImplicationStatus' (see the use of
          'termEvidenceAllowed')
      
      All these changes led to quite bit of error message wibbling
      3f5673f3
  18. 19 Oct, 2016 1 commit
    • Simon Peyton Jones's avatar
      Test for newtype with unboxed argument · 1f09c16c
      Simon Peyton Jones authored
      Newtypes cannot (currently) have an unboxed argument type.
      But Trac #12729 showed that this was only being checked for
      newtypes in H98 syntax; in GADT snytax they were let through.
      
      This patch moves the test to checkValidDataCon, where it properly
      belongs.
      1f09c16c
  19. 13 Oct, 2016 1 commit
    • Simon Peyton Jones's avatar
      Further improve error handling in TcRn monad · 2fdf21bf
      Simon Peyton Jones authored
      This patch builds on the one for Trac #12124, by dealing properly
      with out-of-scope "hole" errors.
      
      This fixes Trac #12529. The hard error coming from visible type application
      is still there, but the out-of-scope error is no longer suppressed.
      
      (Arguably the VTA message should be suppressed somehow, but that's a
      battle for another day.)
      2fdf21bf
  20. 12 Oct, 2016 1 commit
  21. 08 Oct, 2016 1 commit
  22. 05 Oct, 2016 1 commit
  23. 30 Sep, 2016 1 commit
    • Simon Peyton Jones's avatar
      Fix impredicativity (again) · b612da66
      Simon Peyton Jones authored
      This patch fixes Trac #12616.
      
      Dignosis.  In TcUnify.tc_sub_type_ds we were going to some trouble to
      support co- and contra-variance even for impredicative types.  With
      -XImpredicativeTYpes, this allowed a unification variable to be
      unified with a polytype (probably wrongly) and that caused later
      trouble in the constraint solver, where -XImpredicativeTypes was /not/
      on.  In effect, -XImpredicativeTypes can't be switched on locally.
      
      Why did we want ImpredicativeTypes locally?  Because the program
      generated by GND for a higher-rank method involved impredicative
      instantation of 'coerce':
            op = coerce op   -- where op has a higher rank type
      See Note [Newtype-deriving instances] in TcGenDeriv.
      
      Cure.
      
      1.  It is ghastly to rely on ImpredicativeTypes (a 100% flaky
          feature) to instantiate coerce polymorphically.  Happily we
          now have Visible Type Application, so I've used that instead
          which should be solid and reliable.
      
      2.  I deleted the code in tc_sub_type_ds that allows the constraint
          solver to "look through" a unification variable to find a
          polytype.  That used to be essential in the days of ReturnTv,
          but it's utterly unreliable and should be consigned to the dustbin
          of history.  (We have ExpType now for the essential uses.)
      
      Tests involving ImpredicativeTypes are affected, but I'm not worried
      about them... it's advertised as a feature you can't rely on, and
      I want to reform it outright.
      b612da66
  24. 12 Sep, 2016 1 commit
    • Simon Peyton Jones's avatar
      Be less picky about reporing inaccessible code · 03541cba
      Simon Peyton Jones authored
      Triggered by the discussion on Trac #12466, this patch
      makes GHC less aggressive about reporting an error when
      there are insoluble Givens.
      
      Being so agressive was making some libraries fail to
      compile, and is arguably wrong in at least some cases.
      See the discussion on the ticket.
      
      Several test now pass when they failed before; see
      the files-modified list for this patch.
      03541cba
  25. 31 Aug, 2016 1 commit
  26. 21 Aug, 2016 2 commits
  27. 17 Aug, 2016 1 commit
  28. 01 Aug, 2016 1 commit
  29. 05 Jul, 2016 1 commit
    • Simon Peyton Jones's avatar
      Check generic-default method for ambiguity · 85aa6ef0
      Simon Peyton Jones authored
      Fixes Trac #7497 and #12151.   In some earlier upheaval I introduced
      a bug in the ambiguity check for genreric-default method.
      
      This patch fixes it.  But in fixing it I realised that the
      sourc-location of any such error message was bogus, so I fixed
      that too, which involved a slightly wider change; see the
      comments with TcMethInfo.
      85aa6ef0
  30. 23 Jun, 2016 1 commit
  31. 18 May, 2016 1 commit
  32. 04 May, 2016 1 commit
  33. 22 Apr, 2016 2 commits
    • Simon Peyton Jones's avatar
      Warn about simplifiable class constraints · 9421b0c7
      Simon Peyton Jones authored
      Provoked by Trac #11948, this patch adds a new warning to GHC
      
        -Wsimplifiable-class-constraints
      
      It warns if you write a class constraint in a type signature that
      can be simplified by an existing instance declaration.  Almost always
      this means you should simplify it right now; type inference is very
      fragile without it, as #11948 shows.
      
      I've put the warning as on-by-default, but I suppose that if there are
      howls of protest we can move it out (as happened for -Wredundant-constraints.
      
      It actually found an example of an over-complicated context in CmmNode.
      
      Quite a few tests use these weird contexts to trigger something else,
      so I had to suppress the warning in those.
      
      The 'haskeline' library has a few occurrences of the warning (which
      I think should be fixed), so I switched it off for that library in
      warnings.mk.
      
      The warning itself is done in TcValidity.check_class_pred.
      
      HOWEVER, when type inference fails we get a type error; and the error
      suppresses the (informative) warning.  So as things stand, the warning
      only happens when it doesn't cause a problem.  Not sure what to do
      about this, but this patch takes us forward, I think.
      9421b0c7
    • Simon Peyton Jones's avatar
      Do not use defaulting in ambiguity check · edf54d72
      Simon Peyton Jones authored
      This fixes Trac #11947.  See TcSimplify
      Note [No defaulting in the ambiguity check]
      edf54d72
  34. 11 Apr, 2016 1 commit
    • Rik Steenkamp's avatar
      Fix a closed type family error message · 46e8f199
      Rik Steenkamp authored and Ben Gamari's avatar Ben Gamari committed
      Now we check whether a closed type family's equation is headed with
      the correct type before we kind-check the equation.
      
      Also, instead of "expected only no parameters" we now generate the
      message "expected no parameters".
      
      Fixes #11623.
      
      Reviewers: simonpj, austin, bgamari
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: simonpj, goldfire, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2089
      
      GHC Trac Issues: #11623
      46e8f199
  35. 07 Apr, 2016 1 commit