1. 11 Dec, 2015 1 commit
  2. 10 Dec, 2015 2 commits
  3. 09 Dec, 2015 4 commits
    • Gabor Greif's avatar
      More typos in comments/docs · 688069ca
      Gabor Greif authored
      688069ca
    • Simon Peyton Jones's avatar
      Improve documentation for DeriveAnyClass · 83178931
      Simon Peyton Jones authored
      c.f. Trac #9968
      83178931
    • Simon Peyton Jones's avatar
      Comments only · e9ea0209
      Simon Peyton Jones authored
      e9ea0209
    • Simon Peyton Jones's avatar
      Fix DeriveAnyClass (Trac #9968) · af77089b
      Simon Peyton Jones authored
      The main issue concerned things like
      
         data T a = MkT a deriving( C Int )
      
      which is supposed to generate
      
         instance C Int (T a) where {}
      
      But the 'Int' argument (called cls_tys in the code) wasn't
      even being passed to inferConstraints and mk_data_eqn, so it
      really had no chance.   DeriveAnyClass came along after this
      code was written!
      
      Anyway I did quite a bit of tidying up in inferConstraints.
      
      Also I discovered that this case was not covered at all
      
         data T a b = MkT a b deriving( Bifunctor )
      
      What constraints should we generate for the instance context?
      We can deal with classes whose last arg has kind *, like Eq, Ord;
      or (* -> *), like Functor, Traversable.  But we really don't have
      a story for classes whose last arg has kind (* -> * -> *).
      
      So I augmented checkSideConditions to check for that and give
      a sensible error message.
      
      ToDo: update the user manual.
      af77089b
  4. 08 Dec, 2015 14 commits
  5. 07 Dec, 2015 17 commits
  6. 06 Dec, 2015 2 commits
    • Herbert Valerio Riedel's avatar
      Tweak use of AC_USE_SYSTEM_EXTENSIONS · 8b422142
      Herbert Valerio Riedel authored
      This makes sure that `AC_USE_SYSTEM_EXTENSIONS` (which
      implies `AC_PROG_CC`) is called after the
      `AC_ARG_WITH([cc],,)` invocation, so that the proper
      CC setting is in scope. Otherwise this can break cross-compilation.
      
      This also needs to pull in a submodule update for `unix`
      
      This is a follow-up commit to
      7af29da0
      which hopefully fixes #11168
      8b422142
    • Herbert Valerio Riedel's avatar
      Implement new `-fwarn-noncanonical-monoid-instances` · 986ceb16
      Herbert Valerio Riedel authored
      This is similiar to the `-fwarn-noncanonical-monad-instances` warning
      implemented via #11128, but applies to `Semigroup`/`Monoid` instead
      and the `(<>)`/`mappend` methods (of which `mappend` is planned to move
      out of `Monoid` at some point in the future being redundant and thus
      error-prone).
      
      This warning is contained in `-Wcompat` but not in `-Wall`.
      
      This addresses #11150
      
      Reviewed By: quchen
      
      Differential Revision: https://phabricator.haskell.org/D1553
      986ceb16