1. 09 Jun, 2015 1 commit
  2. 05 Jun, 2015 1 commit
    • eir@cis.upenn.edu's avatar
      Fix #10489 · 61b96a86
      eir@cis.upenn.edu authored
      Dang, roles are annoying.
      
      Test case: typecheck/should_compile/T10489
      61b96a86
  3. 02 Jun, 2015 1 commit
  4. 19 May, 2015 1 commit
  5. 07 May, 2015 1 commit
  6. 29 Apr, 2015 1 commit
    • 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
  7. 22 Apr, 2015 1 commit
  8. 16 Apr, 2015 1 commit
  9. 15 Apr, 2015 1 commit
    • Simon Peyton Jones's avatar
      Fix fundep coverage-condition check for poly-kinds · 49d9b009
      Simon Peyton Jones authored
      See Note [Closing over kinds in coverage] in FunDeps.
      I'd already fixed this bug once, for Trac #8391, but I put the
      call to closeOverKinds in the wrong place, so Trac #10109
      failed.  (It checks the /liberal/ coverage condition, which
      
      The fix was easy: move the call to the right place!
      49d9b009
  10. 07 Apr, 2015 2 commits
    • Edward Z. Yang's avatar
      Axe one-shot sig-of · 1d5c887c
      Edward Z. Yang authored
      
      
      Summary:
      We're getting rid of -sig-of foo:A usage, because
      it doesn't make sense in any compilation mode besides one-shot,
      and we don't expect users to use it anyway.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D789
      1d5c887c
    • Simon Peyton Jones's avatar
      More aggressive Given/Wanted overlap check · 8b7ceece
      Simon Peyton Jones authored
      This fixes Trac #10195
      
      For some reason we considered untouchability before, but Trac #10195
      shows that this is positively worng.
      
      See Note [Instance and Given overlap] in TcInteract.
      
      Looking at the Git log, it seems that this bug was introduced at the
      same time that we introduced the Given/Wanted overlap check in the first
      place.
      8b7ceece
  11. 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
  12. 22 Mar, 2015 1 commit
  13. 16 Mar, 2015 1 commit
  14. 07 Mar, 2015 1 commit
    • Iavor S. Diatchki's avatar
      Custom `Typeable` solver, that keeps track of kinds. · b359c886
      Iavor S. Diatchki authored
      Summary:
      This implements the new `Typeable` solver: when GHC sees `Typeable` constraints
      it solves them on the spot.
      
      The current implementation creates `TyCon` representations on the spot.
      
      Pro: No overhead at all in code that does not use `Typeable`
      Cons: Code that uses `Typeable` may create multipe `TyCon` represntations.
      
      We have discussed an implementation where representations of `TyCons` are
      computed once, in the module, where a datatype is declared.  This would
      lead to more code being generated:  for a promotable datatype we need to
      generate `2 + number_of_data_cons` type-constructro representations,
      and we have to do that for all programs, even ones that do not intend to
      use typeable.
      
      I added code to emit warning whenevar `deriving Typeable` is encountered---
      the idea being that this is not needed anymore, and shold be fixed.
      
      Also, we allow `instance Typeable T` in .hs-boot files, but they result
      in a warning, and are ignored.  This last one was to avoid breaking exisitng
      code, and should become an error, eventually.
      
      Test Plan:
      1. GHC can compile itself.
      2. I compiled a number of large libraries, including `lens`.
          - I had to make some small changes:
            `unordered-containers` uses internals of `TypeReps`, so I had to do a 1 line fix
          - `lens` needed one instance changed, due to a poly-kinded `Typeble` instance
      
      3. I also run some code that uses `syb` to traverse a largish datastrucutre.
      I didn't notice any signifiant performance difference between the 7.8.3 version,
      and this implementation.
      
      Reviewers: simonpj, simonmar, austin, hvr
      
      Reviewed By: austin, hvr
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D652
      
      GHC Trac Issues: #9858
      b359c886
  15. 20 Feb, 2015 1 commit
  16. 15 Feb, 2015 1 commit
  17. 27 Jan, 2015 1 commit
  18. 19 Jan, 2015 1 commit
  19. 16 Jan, 2015 1 commit
  20. 09 Jan, 2015 1 commit
  21. 06 Jan, 2015 1 commit
  22. 17 Dec, 2014 1 commit
  23. 12 Dec, 2014 1 commit
    • eir@cis.upenn.edu's avatar
      Rewrite `Coercible` solver · 0cc47eb9
      eir@cis.upenn.edu authored
      Summary:
      This is a rewrite of the algorithm to solve for Coercible "instances".
      
      A preliminary form of these ideas is at
      https://ghc.haskell.org/trac/ghc/wiki/Design/NewCoercibleSolver
      
      The basic idea here is that the `EqPred` constructor of `PredTree`
      now is parameterised by a new type `EqRel` (where
      `data EqRel = NomEq | ReprEq`). Thus, every equality constraint can
      now talk about nominal equality (the usual case) or representational
      equality (the `Coercible` case).
      
      This is a change from the previous
      behavior where `Coercible` was just considered a regular class with
      a special case in `matchClassInst`.
      
      Because of this change, representational equalities are now
      canonicalized just like nominal ones, allowing more equalities
      to be solved -- in particular, the case at the top of #9117.
      
      A knock-on effect is that the flattener must be aware of the
      choice of equality relation, because the inert set now stores
      both representational inert equalities alongside the nominal
      inert equalities. Of course, we can use representational equalities
      to rewrite only within another representational equality --
      thus the parameterization of the flattener.
      
      A nice side effect of this change is that I've introduced a new
      type `CtFlavour`, which tracks G vs. W vs. D, removing some ugliness
      in the flattener.
      
      This commit includes some refactoring as discussed on D546.
      It also removes the ability of Deriveds to rewrite Deriveds.
      
      This fixes bugs #9117 and #8984.
      
      Reviewers: simonpj, austin, nomeata
      
      Subscribers: carter, thomie
      
      Differential Revision: https://phabricator.haskell.org/D546
      
      GHC Trac Issues: #9117, #8984
      0cc47eb9
  24. 10 Dec, 2014 2 commits
  25. 26 Nov, 2014 1 commit
  26. 24 Nov, 2014 1 commit
  27. 21 Nov, 2014 3 commits
    • Merijn Verstraaten's avatar
      Add -fdefer-typed-holes flag which defers hole errors to runtime. · 2cc854b7
      Merijn Verstraaten authored
      
      
      Summary:
      As proposed by Richard on Trac. This patch adds a new flag -fdefer-typed-holes
      and changes the semantics of the -fno-warn-typed-holes flag.
      
      To summarise, by default GHC has typed holes enabled and produces a compile
      error when it encounters a typed hole.
      
      When -fdefer-type-errors OR -fdefer-typed-holes is enabled, hole errors are
      converted to warnings and result in runtime errors when evaluated.
      
      The warning flag -fwarn-typed-holes is on by default. Without -fdefer-type-errors
      or -fdefer-typed-holes this flag is a no-op, since typed holes are an error
      under these conditions. If either of the defer flags are enabled (converting
      typed hole errors into warnings) the -fno-warn-typed-holes flag disables the
      warnings. This means compilation silently succeeds and evaluating a hole will
      produce a runtime error.
      
      The rationale behind allowing typed holes warnings to be silenced is that tools
      like Syntastic for vim highlight warnings and hole warnings may be undesirable.
      Signed-off-by: Merijn Verstraaten's avatarMerijn Verstraaten <merijn@inconsistent.nl>
      
      Test Plan: validate
      
      Reviewers: austin, simonpj, thomie
      
      Reviewed By: simonpj, thomie
      
      Subscribers: Fuuzetsu, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D442
      
      GHC Trac Issues: #9497
      
      Conflicts:
      	compiler/main/DynFlags.hs
      2cc854b7
    • Simon Peyton Jones's avatar
    • Simon Peyton Jones's avatar
      Test Trac #9569 · 230b013b
      Simon Peyton Jones authored
      230b013b
  28. 20 Nov, 2014 1 commit
  29. 12 Nov, 2014 2 commits
  30. 04 Nov, 2014 1 commit
  31. 24 Oct, 2014 1 commit
    • Edward Z. Yang's avatar
      Implementation of hsig (module signatures), per #9252 · aa479953
      Edward Z. Yang authored
      
      
      Summary:
      Module signatures, like hs-boot files, are Haskell modules which omit
      value definitions and contain only signatures.  This patchset implements
      one particular aspect of module signature, namely compiling them against
      a concrete implementation.  It works like this: when we compile an hsig
      file, we must be told (via the -sig-of flag) what module this signature
      is implementing.  The signature is compiled into an interface file which
      reexports precisely the entities mentioned in the signature file.  We also
      verify that the interface is compatible with the implementation.
      
      This feature is useful in a few situations:
      
          1. Like explicit import lists, signatures can be used to reduce
          sensitivity to upstream changes.  However, a signature can be defined
          once and then reused by many modules.
      
          2. Signatures can be used to quickly check if a new upstream version
          is compatible, by typechecking just the signatures and not the actual
          modules.
      
          3. A signature can be used to mediate separate modular development,
          where the signature is used as a placeholder for functionality which
          is loaded in later.  (This is only half useful at the moment, since
          typechecking against signatures without implementations is not implemented
          in this patchset.)
      
      Unlike hs-boot files, hsig files impose no performance overhead.
      
      This patchset punts on the type class instances (and type families) problem:
      instances simply leak from the implementation to the signature.  You can
      explicitly specify what instances you expect to have, and those will be checked,
      but you may get more instances than you asked for.  Our eventual plan is
      to allow hiding instances, but to consider all transitively reachable instances
      when considering overlap and soundness.
      
      ToDo: signature merging: when a module is provided by multiple signatures
      for the same base implementation, we should not consider this ambiguous.
      
      ToDo: at the moment, signatures do not constitute use-sites, so if you
      write a signature for a deprecated function, you won't get a warning
      when you compile the signature.
      
      Future work: The ability to feed in shaping information so that we can take
      advantage of more type equalities than might be immediately evident.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate and new tests
      
      Reviewers: simonpj, simonmar, hvr, austin
      
      Subscribers: simonmar, relrod, ezyang, carter, goldfire
      
      Differential Revision: https://phabricator.haskell.org/D130
      
      GHC Trac Issues: #9252
      aa479953
  32. 20 May, 2014 2 commits
  33. 07 Mar, 2014 2 commits