1. 22 Apr, 2015 1 commit
  2. 16 Apr, 2015 1 commit
  3. 14 Apr, 2015 1 commit
    • Simon Peyton Jones's avatar
      Do not allow Typeable on constraints (Trac #9858) · 7b042d5a
      Simon Peyton Jones authored
      The astonishingly-ingenious trio of
      Shachaf Ben-Kiki, Ørjan Johansen and Nathan van Doorn
      managed to persuade GHC 7.10.1 to cough up unsafeCoerce.
      
      That is very bad. This patch fixes it by no allowing Typable
      on Constraint-kinded things.  And that seems right, since
      it is, in effect, a form of impredicative polymorphism,
      which Typeable definitely doesn't support.
      
      We may want to creep back in the direction of allowing
      Typeable on constraints one day, but this is a good
      fix for now, and closes a terrible hole.
      7b042d5a
  4. 08 Apr, 2015 1 commit
  5. 07 Apr, 2015 2 commits
  6. 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
  7. 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
  8. 04 Mar, 2015 1 commit
    • Simon Peyton Jones's avatar
      A raft of small changes associated with -XConstrainedClassMethods · f66e0e69
      Simon Peyton Jones authored
      See Trac #7854.  Specifically:
      
      * Major clean up and simplification of check_op in checkValidClass;
        specifically
           - use checkValidType on the entire method-selector type to detect
             ambiguity
           - put a specific test for -XConstrainedClassMethods
      
      * Make -XConstrainedClassMethods be implied by -XMultiParamTypeClasses
        (a bit ad-hoc but see #7854), and document in the user manual.
      
      * Do the checkAmbiguity test just once in TcValidity.checkValidType,
        rather than repeatedly at every level. See Note [When to call checkAmbiguity]
      
      * Add -XAllowAmbiguousTypes in GHC.IP, since 'ip' really is ambiguous.
        (It's a rather magic function.)
      
      * Improve location info for check_op in checkValidClass
      
      * Update quite a few tests, which had genuinely-ambiguous class
        method signatures.  Some I fixed by making them unambiguous; some
        by adding -XAllowAmbiguousTypes
      f66e0e69
  9. 23 Dec, 2014 1 commit
    • Simon Peyton Jones's avatar
      Eliminate so-called "silent superclass parameters" · a6f0f5ab
      Simon Peyton Jones authored
      The purpose of silent superclass parameters was to solve the
      awkward problem of superclass dictinaries being bound to bottom.
      See THE PROBLEM in Note [Recursive superclasses] in TcInstDcls
      
      Although the silent-superclass idea worked,
      
        * It had non-local consequences, and had effects even in Haddock,
          where we had to discard silent parameters before displaying
          instance declarations
      
        * It had unexpected peformance costs, shown up by Trac #3064 and its
          test case.  In monad-transformer code, when constructing a Monad
          dictionary you had to pass an Applicative dictionary; and to
          construct that you neede a Functor dictionary. Yet these extra
          dictionaries were often never used.  (All this got much worse when
          we added Applicative as a superclass of Monad.) Test T3064
          compiled *far* faster after silent superclasses were eliminated.
      
        * It introduced new bugs.  For example SilentParametersOverlapping,
          T5051, and T7862, all failed to compile because of instance overlap
          directly because of the silent-superclass trick.
      
      So this patch takes a new approach, which I worked out with Dimitrios
      in the closing hours before Christmas.  It is described in detail
      in THE PROBLEM in Note [Recursive superclasses] in TcInstDcls.
      
      Seems to work great!
      
      Quite a bit of knock-on effect
      
       * The main implementation work is in tcSuperClasses in TcInstDcls
         Everything else is fall-out
      
       * IdInfo.DFunId no longer needs its n-silent argument
         * Ditto IDFunId in IfaceSyn
         * Hence interface file format changes
      
       * Now that DFunIds do not have silent superclass parameters, printing
         out instance declarations is simpler. There is tiny knock-on effect
         in Haddock, so that submodule is updated
      
       * I realised that when computing the "size of a dictionary type"
         in TcValidity.sizePred, we should be rather conservative about
         type functions, which can arbitrarily increase the size of a type.
         Hence the new datatype TypeSize, which has a TSBig constructor for
         "arbitrarily big".
      
       * instDFunType moves from TcSMonad to Inst
      
       * Interestingly, CmmNode and CmmExpr both now need a non-silent
         (Ord r) in a couple of instance declarations. These were previously
         silent but must now be explicit.
      
       * Quite a bit of wibbling in error messages
      a6f0f5ab
  10. 10 Dec, 2014 2 commits
  11. 02 Dec, 2014 1 commit
  12. 01 Dec, 2014 1 commit
  13. 27 Nov, 2014 1 commit
  14. 24 Nov, 2014 1 commit
  15. 21 Nov, 2014 2 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
      Delete duplicated tests · e6391208
      Simon Peyton Jones authored
      e6391208
  16. 20 Nov, 2014 3 commits
  17. 12 Nov, 2014 1 commit
    • eir@cis.upenn.edu's avatar
      Fix #9404 by removing tcInfExpr. · 1e2002d8
      eir@cis.upenn.edu authored
      See the ticket for more info about the new algorithm. This is a small
      simplification, unifying the treatment of type checking in a few
      similar situations.
      1e2002d8
  18. 06 Nov, 2014 1 commit
  19. 04 Nov, 2014 1 commit
  20. 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
  21. 26 Sep, 2014 2 commits
  22. 12 Aug, 2014 1 commit
  23. 08 Aug, 2014 1 commit
    • Simon Peyton Jones's avatar
      Implement the final change to INCOHERENT from Trac #9242 · dff0623d
      Simon Peyton Jones authored
      The change here is to make INCOHERENT slightly more permissive:
      
        if the selected candidate is incoherent
        then ignore all unifying candidates
      
      This allows us to move the {-# INCOHERENT #-} pragma from
        from   instance Typeable (f a)
        to     Typeable (n:Nat) and Typable (s:Symbol)
      where it belongs, and where Trac #9242 said it should be.
      
      I don't think this will affect anyone.
      
      I've updated the user manual.
      dff0623d
  24. 17 Jul, 2014 1 commit
  25. 12 Jul, 2014 1 commit
  26. 20 Jun, 2014 1 commit
    • Simon Peyton Jones's avatar
      Reject forall types in constraints in signatures · 9c621e9b
      Simon Peyton Jones authored
      Fixes Trac #9196.  Thanks to archblob for an initial stab at this.
      In the end I fixed it in the kind checker rather than the subsequent
      validity check, (a) so that the error messages look more uniform,
      and (b) so that I did not need to meddle with isPredTy.
      9c621e9b
  27. 11 Jun, 2014 1 commit
  28. 28 Apr, 2014 1 commit
    • Simon Peyton Jones's avatar
      Do type-class defaulting even if there are insoluble constraints · ba2e2014
      Simon Peyton Jones authored
      The argument in Trac #9033 is very compelling: we should not report 20
      errors, fix one, and have the other 19 disappear.  They were spurious
      in the first place.
      
      The fix was easy; do type-class defaulting uncondionally, rather than
      only if there are no insoluble constraints.
      
      See Note [When to do type-class defaulting] in TcSimplify.
      
      Error messages generally improve, especially tc211 which actually
      had an example of precisely this phenomenon.
      ba2e2014
  29. 24 Mar, 2014 1 commit
  30. 14 Mar, 2014 1 commit
    • eir@cis.upenn.edu's avatar
      Remove "Safe mode" check for Coercible instances · 59722295
      eir@cis.upenn.edu authored
      We assume that library authors supply correct role annotations
      for their types, and therefore we do not need to check for
      the availability of data constructors in Safe mode. See
      discussion in #8725. This effectively fixes #8827 and #8826.
      59722295
  31. 20 Feb, 2014 1 commit
    • Erik de Castro Lopo's avatar
      Add test case for #8806. · 55cc01a9
      Erik de Castro Lopo authored
      GHC 7.6.3 and earlier should fail to type check this but don't.
      This was fixed some time between the 7.6.3 and the 7.8rc1 release, so
      we're just adding a test to prevent future regressions.
      55cc01a9
  32. 28 Dec, 2013 1 commit
  33. 29 Nov, 2013 1 commit
  34. 22 Nov, 2013 1 commit