1. 17 Oct, 2016 1 commit
  2. 10 Oct, 2016 2 commits
    • Simon Peyton Jones's avatar
      More tests for Trac #12522 · a6111b8c
      Simon Peyton Jones authored
      These ones test the variations in coment:15 of the ticket
      a6111b8c
    • Simon Peyton Jones's avatar
      Orient improvement constraints better · b255ae7b
      Simon Peyton Jones authored
      This patch fixes an infinite loop in the constraint solver,
      shown up by Trac #12522.
      
      The solution is /very/ simple: just reverse the orientation of the
      derived constraints arising from improvement using type-family
      injectivity.  I'm not very proud of the fix --- it seems fragile
      --- but it has the very great merit of simplicity, and it works
      fine.
      
      See Note [Improvement orientation] in TcInteract, and some
      discussion on the Trac ticket.
      b255ae7b
  3. 28 Jun, 2016 2 commits
  4. 22 Jun, 2016 1 commit
    • Simon Peyton Jones's avatar
      Expand given superclasses more eagerly · ce97b729
      Simon Peyton Jones authored
      This patch fixes Trac #12175, another delicate corner case of
      Note [Instance and Given overlap] in TcInteract.
      
      In #12175 we were not expanding given superclasses eagerly
      enough. It was easy to fix, and is actually rather neater than
      before.
      
      See Note [Eagerly expand given superclasses] in TcCanonical.
      The main change is to move the eager expansion of given superclasses
      to canClassNC.
      ce97b729
  5. 21 Mar, 2016 1 commit
  6. 15 Mar, 2016 1 commit
    • eir@cis.upenn.edu's avatar
      Allow eager unification with type families. · 3f5d1a13
      eir@cis.upenn.edu authored
      Previously, checkTauTvUpdate, used in the eager unifier (TcUnify)
      right before writing to a metavar, refused to write a metavar to
      a type involving type functions. The reason for this was given
      in a Note, but the Note didn't make all that much sense and even
      admitted that it was a bit confused. The Note, in turn, referred
      to another Note, which it was quite sceptical of, as well.
      
      The type-family check was slowing down performance, so I tried
      removing it, running the tests referred to in the Note. The tests
      all passed without the check. Looking at more test results, I
      saw several error messages improve without the check, and some cases
      where GHC looped (T7788, in particular) it now doesn't.
      
      So, all in all, quite a win: Two hairy Notes removed, several lines
      of code removed, better performance, and improved output.
      
      [skip ci]
      3f5d1a13
  7. 07 Mar, 2016 1 commit
  8. 25 Feb, 2016 1 commit
    • thomie's avatar
      Mark tests for #11643, #11644, #11645 and #9406 expect_broken · 90fa8cf2
      thomie authored
      For opt_ways or prof_ways only.
      
      indexed-types/should_compile/all.T called setTestOpts to not run
      the tests with opt_ways. Since I'm finding regressions for opt_ways, I
      removed it. This only makes a difference when running
      `./validate --slow` or `make slowtest`.
      
      Update submodule hpc.
      90fa8cf2
  9. 18 Feb, 2016 1 commit
    • Simon Peyton Jones's avatar
      Take type-function arity into account · a008eadf
      Simon Peyton Jones authored
      ...when computing the size of a call on the RHS of a type
      instance declaration.
      
      This came up in Trac #11581.  The change is in
         TcType.tcTyFamInsts
      which now trims the type arguments in a call.  See the
      comments with that function definition.
      a008eadf
  10. 15 Feb, 2016 1 commit
  11. 26 Jan, 2016 1 commit
    • Ryan Scott's avatar
      Split off -Wunused-type-variables from -Wunused-matches · 6817703b
      Ryan Scott authored
      Summary:
      Previously, `-Wunused-matches` would fire whenever it detected unused type
      variables in a type family or data family instance. This can be annoying for
      users who wish to use type variable names as documentation, as being
      `-Wall`-compliant would mean that they'd have to prefix many of their type
      variable names with underscores, making the documentation harder to read.
      
      To avoid this, a new warning `-Wunused-type-variables` was created that only
      encompasses unused variables in family instances. `-Wunused-matches` reverts
      back to its role of only warning on unused term-level pattern names. Unlike
      `-Wunused-matches`, `-Wunused-type-variables` is not implied by `-Wall`.
      
      Fixes #11451.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, ekmett, austin, hvr, simonpj, bgamari
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1825
      
      GHC Trac Issues: #11451
      6817703b
  12. 18 Jan, 2016 1 commit
    • Simon Peyton Jones's avatar
      Fix typecheck of default associated type decls · cb24e684
      Simon Peyton Jones authored
      This bug was thrown up by Trac #11361, but I found that the
      problem was deeper: GHC was allowing
      
        class C a where
          type F (a :: k) :: *
          type F (x :: *) = x    -- Not right!
      
      (Which is now indexed-types/should_compile/T11361a.)
      
      Anyway the fix is relatively simple; use tcMatchTys in
      tcDefaultAssocDecl.
      
      Merge to 8.0 branch.
      cb24e684
  13. 16 Jan, 2016 1 commit
    • Simon Peyton Jones's avatar
      Fix a number of subtle solver bugs · 9308c736
      Simon Peyton Jones authored
      As a result of some other unrelated changes I found that
      IndTypesPerf was failing, and opened Trac #11408.  There's
      a test in indexed-types/should-compile/T11408.
      
      The bug was that a type like
       forall t. (MT (UL t) (UR t) ~ t) => UL t -> UR t -> Int
      is in fact unambiguous, but it's a bit subtle to prove
      that it is unambiguous.
      
      In investigating, Dimitrios and I found several subtle
      bugs in the constraint solver, fixed by this patch
      
      * canRewrite was missing a Derived/Derived case.  This was
        lost by accident in Richard's big kind-equality patch.
      
      * Interact.interactTyVarEq would discard [D] a ~ ty if there
        was a [W] a ~ ty in the inert set.  But that is wrong because
        the former can rewrite things that the latter cannot.
        Fix: a new function eqCanDischarge
      
      * In TcSMonad.addInertEq, the process was outright wrong for
        a Given/Wanted in the (GWModel) case.  We were adding a new
        Derived without kicking out things that it could rewrite.
        Now the code is simpler (no special GWModel case), and works
        correctly.
      
      * The special case in kickOutRewritable for [W] fsk ~ ty,
        turns out not to be needed.  (We emit a [D] fsk ~ ty which
        will do the job.
      
      I improved comments and documentation, esp in TcSMonad.
      9308c736
  14. 21 Dec, 2015 1 commit
    • msosn's avatar
      Warn about unused type variables in type families · eb7796f1
      msosn authored
      The warnings are enabled with the flag -fwarn-unused-matches, the same
      one that enables warnings on the term level.
      
      Identifiers starting with an underscore are now always parsed as type
      variables.  When the NamedWildCards extension is enabled, the renamer
      replaces those variables with named wildcards.
      
      An additional NameSet nwcs is added to LocalRdrEnv. It's used to keep
      names of the type variables that should be replaced with wildcards.
      
      While renaming HsForAllTy, when a name is explicitly bound it is removed
      from the nwcs NameSet. As a result, the renamer doesn't replace them in
      the quantifier body. (Trac #11098)
      
      Fixes #10982, #11098
      
      Reviewers: alanz, bgamari, hvr, austin, jstolarek
      
      Reviewed By: jstolarek
      
      Subscribers: goldfire, mpickering, RyanGlScott, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1576
      
      GHC Trac Issues: #10982
      eb7796f1
  15. 15 Dec, 2015 1 commit
    • Simon Peyton Jones's avatar
      Allow recursive (undecidable) superclasses · 6eabb6dd
      Simon Peyton Jones authored
      This patch fulfils the request in Trac #11067, #10318, and #10592,
      by lifting the conservative restrictions on superclass constraints.
      
      These restrictions are there (and have been since Haskell was born) to
      ensure that the transitive superclasses of a class constraint is a finite
      set.  However (a) this restriction is conservative, and can be annoying
      when there really is no recursion, and (b) sometimes genuinely recursive
      superclasses are useful (see the tickets).
      
      Dimitrios and I worked out that there is actually a relatively simple way
      to do the job. It’s described in some detail in
      
         Note [The superclass story] in TcCanonical
         Note [Expanding superclasses] in TcType
      
      In brief, the idea is to expand superclasses only finitely, but to
      iterate (using a loop that already existed) if there are more
      superclasses to explore.
      
      Other small things
      
      - I improved grouping of error messages a bit in TcErrors
      
      - I re-centred the haddock.compiler test, which was at 9.8%
        above the norm, and which this patch pushed slightly over
      6eabb6dd
  16. 10 Dec, 2015 1 commit
  17. 12 Oct, 2015 1 commit
  18. 19 Sep, 2015 1 commit
    • eir@cis.upenn.edu's avatar
      Fix #10815 by kind-checking type patterns against known kinds. · 2d4db40a
      eir@cis.upenn.edu authored
      tcFamTyPats now must take information about the instantiation of any
      class variables, when checking the instance of an associated type.
      
      Getting this to work out required some unexpected refactoring in
      TcDeriv. TcDeriv needs to look at class instances because of the
      possibility of associated datatypes with `deriving` specs. TcDeriv
      worked over the user-specified instances. But any data family instances
      were already processed, and TcDeriv had no way of finding the rep
      tycons. Indeed, TcDeriv *re-type-checked* any data family instances
      in an attempt to rediscover what GHC already knew. So, this commit
      introduces better tracking of compiled data families between TcInstDcls
      and TcDeriv to streamline all of this.
      2d4db40a
  19. 11 Sep, 2015 1 commit
  20. 07 Aug, 2015 1 commit
  21. 04 Aug, 2015 1 commit
    • eir@cis.upenn.edu's avatar
      Fix #10713. · f063bd54
      eir@cis.upenn.edu authored
      When doing the apartness/flattening thing, we really only need to
      eliminate non-generative tycons, not *all* families. (Data families
      are indeed generative!)
      f063bd54
  22. 13 Jul, 2015 2 commits
  23. 15 Jun, 2015 1 commit
  24. 09 Jun, 2015 1 commit
  25. 04 May, 2015 1 commit
    • Adam Gundry's avatar
      Permit empty closed type families · 4efa4213
      Adam Gundry authored
      Fixes #9840 and #10306, and includes an alternative resolution to #8028.
      This permits empty closed type families, and documents them in the user
      guide. It updates the Haddock submodule to support the API change.
      
      Test Plan: Added `indexed-types/should_compile/T9840` and updated
      `indexed-types/should_fail/ClosedFam4` and `th/T8028`.
      
      Reviewers: austin, simonpj, goldfire
      
      Reviewed By: goldfire
      
      Subscribers: bgamari, jstolarek, thomie, goldfire
      
      Differential Revision: https://phabricator.haskell.org/D841
      
      GHC Trac Issues: #9840, #10306
      4efa4213
  26. 29 Apr, 2015 2 commits
    • Simon Peyton Jones's avatar
      Test Trac #10226 · d4a926ba
      Simon Peyton Jones authored
      Fixed by the patch for #10009
      d4a926ba
    • Simon Peyton Jones's avatar
      Improve improvement in the constraint solver · a1275a76
      Simon Peyton Jones authored
      This regrettably-big patch substantially improves the way in which
      "improvement" happens in the constraint solver.  It was triggered by
      trying to crack Trac #10009, but it turned out to solve #10340 as
      well.
      
      The big picture, with several of the trickiest examples, is described
      in Note [The improvement story] in TcInteract.
      
      The major change is this:
      
      * After solving we explicitly try "improvement", by
           - making the unsolved Wanteds into Deriveds
           - allowing Deriveds to rewrite Deriveds
        This more aggressive rewriting "unlocks" some extra
        guess-free unifications.
      
      * The main loop is in TcInteract.solveSimpleWanteds, but I also ended
        up refactoring TcSimplify.simpl_loop, and its surrounding code.
      
        Notably, any insolubles from the Givens are pulled out
        and treated separately, rather than staying in the inert set
        during the solveSimpleWanteds loop.
      
      There are a lot of follow-on changes
      
      * Do not emit generate Derived improvements from Wanteds.
        This saves work in the common case where they aren't needed.
      
      * For improvement we should really do type-class reduction on Derived
        constraints in doTopReactDict.  That entailed changing the GenInst
        constructor a bit; a local and minor change
      
      * Some annoying faffing about with dropping derived constraints;
        see dropDerivedWC, dropDerivedSimples, dropDerivedInsols,
        and their Notes.
      
      * Some substantial refactoring in TcErrors.reportWanteds.
        This work wasn't strictly forced, but I got sucked into it.
        All the changes are in TcErrors.
      
      * Use TcS.unifyTyVar consistently, rather than setWantedTyBind,
        so that unifications are properly tracked.
      
      * Refactoring around solveWantedsTcM, solveWantedsAndDrop.
        They previously guaranteed a zonked result, but it's more
        straightforward for clients to zonk.
      a1275a76
  27. 22 Apr, 2015 1 commit
  28. 23 Mar, 2015 1 commit
    • eir@cis.upenn.edu's avatar
      Do proper depth checking in the flattener to avoid looping. · c1edbdfd
      eir@cis.upenn.edu authored
      This implements (roughly) the plan put forward in comment:14:ticket:7788,
      fixing #7788, #8550, #9554, #10139, and addressing concerns raised in #10079.
      There are some regressions w.r.t. GHC 7.8, but only with pathological type
      families (like F a = F a). This also (hopefully -- don't have a test case)
      fixes #10158. Unsolved problems include #10184 and #10185, which are both
      known deficiencies of the approach used here.
      
      As part of this change, the plumbing around detecting infinite loops has
      changed. Instead of -fcontext-stack and -ftype-function-depth, we now have
      one combined -freduction-depth parameter. Setting it to 0 disbales the
      check, which is now the recommended way to get (terminating) code to
      typecheck in releases. (The number of reduction steps may well change between
      minor GHC releases!)
      
      This commit also introduces a new IntWithInf type in BasicTypes
      that represents an integer+infinity. This type is used in a few
      places throughout the code.
      
      Tests in
        indexed-types/should_fail/T7788
        indexed-types/should_fail/T8550
        indexed-types/should_fail/T9554
        indexed-types/should_compile/T10079
        indexed-types/should_compile/T10139
        typecheck/should_compile/T10184  (expected broken)
        typecheck/should_compile/T10185  (expected broken)
      
      This commit also changes performance testsuite numbers, for the better.
      c1edbdfd
  29. 11 Feb, 2015 1 commit
  30. 06 Feb, 2015 1 commit
  31. 19 Dec, 2014 1 commit
  32. 11 Dec, 2014 1 commit
  33. 01 Dec, 2014 1 commit
  34. 04 Nov, 2014 3 commits