1. 06 Jan, 2015 10 commits
    • Simon Peyton Jones's avatar
      Remove redundant constraints from libraries, discovered by -fwarn-redundant-constraints · c409b6f3
      Simon Peyton Jones authored
      This patch affects libraries, and requires a submodule update.
      
      Some other libraries, maintained by others, have redundant constraints,
      namely:
                 containers
                 haskeline
                 transformers
                 binary
      
      I have suppressed the redundant-constraint warnings by settings in
                 validate-settings.mk
      (in this commit)
      c409b6f3
    • Simon Peyton Jones's avatar
    • Simon Peyton Jones's avatar
      Major patch to add -fwarn-redundant-constraints · 32973bf3
      Simon Peyton Jones authored
      The idea was promted by Trac #9939, but it was Christmas, so I did
      some recreational programming that went much further.
      
      The idea is to warn when a constraint in a user-supplied context is
      redundant.  Everything is described in detail in
        Note [Tracking redundant constraints]
      in TcSimplify.
      
      Main changes:
      
       * The new ic_status field in an implication, of type ImplicStatus.
         It replaces ic_insol, and includes information about redundant
         constraints.
      
       * New function TcSimplify.setImplicationStatus sets the ic_status.
      
       * TcSigInfo has sig_report_redundant field to say whenther a
         redundant constraint should be reported; and similarly
         the FunSigCtxt constructor of UserTypeCtxt
      
       * EvBinds has a field eb_is_given, to record whether it is a given
         or wanted binding. Some consequential chagnes to creating an evidence
         binding (so that we record whether it is given or wanted).
      
       * AbsBinds field abs_ev_binds is now a *list* of TcEvBiinds;
         see Note [Typechecking plan for instance declarations] in
         TcInstDcls
      
       * Some significant changes to the type checking of instance
         declarations; Note [Typechecking plan for instance declarations]
         in TcInstDcls.
      
       * I found that TcErrors.relevantBindings was failing to zonk the
         origin of the constraint it was looking at, and hence failing to
         find some relevant bindings.  Easy to fix, and orthogonal to
         everything else, but hard to disentangle.
      
      Some minor refactorig:
      
       * TcMType.newSimpleWanteds moves to Inst, renamed as newWanteds
      
       * TcClassDcl and TcInstDcls now have their own code for typechecking
         a method body, rather than sharing a single function. The shared
         function (ws TcClassDcl.tcInstanceMethodBody) didn't have much code
         and the differences were growing confusing.
      
       * Add new function TcRnMonad.pushLevelAndCaptureConstraints, and
         use it
      
       * Add new function Bag.catBagMaybes, and use it in TcSimplify
      32973bf3
    • Simon Peyton Jones's avatar
      Print singleton consraints without parens · da9b2ec3
      Simon Peyton Jones authored
      The main change is in TypeRep.pprTheta, so we print
             Eq a
      for a singleton, but
            (Eq a, Show a)
      for multiple constraints.
      
      There are lots of trivial knock-on changes to error messages
      da9b2ec3
    • Simon Peyton Jones's avatar
      Use a less fragile method for defaulting · d4f460fe
      Simon Peyton Jones authored
      When doing top-level defaulting, in TcSimplify.applyDefaultingRules, we
      were temporarily making a unification variable equal to the default type
      (Integer, say, or Float), as a 'given', and trying to solve. But this
      relied on the unification variable being untouchable, which seems
      complicated.  It's much simpler just to generate a new set of
      constraints to solve, using newWantedEvVarNC in disambigGroup.
      
      (I tripped over an ASSERT failure, and this solved it in a robust way.)
      d4f460fe
    • Simon Peyton Jones's avatar
      Always generalise a partial type signature · 28299d68
      Simon Peyton Jones authored
      This fixes an ASSERT failure in TcBinds.  The problem was that we
      were generating NoGen plan for a function with a partial type signature,
      and that led to confusion and lost invariants.
      
      See Note [Partial type signatures and generalisation] in TcBinds
      28299d68
    • Simon Peyton Jones's avatar
      Replace fixVarSet with transCloVarSet · 8e2ed2c7
      Simon Peyton Jones authored
      I think the new implementation is a bit more efficient, because
      it uses a work-list, rather than iterating over the entire set
      every time
      8e2ed2c7
    • Simon Peyton Jones's avatar
      Modify a couple of error messages slightly · 00e1fc1b
      Simon Peyton Jones authored
      In particular
        In the type signature for:
           f :: Int -> Int
      I added the colon
      
      Also reword the "maybe you haven't applied a function to enough arguments?"
      suggestion to make grammatical sense.
      
      These tiny changes affect a lot of error messages.
      00e1fc1b
    • Simon Peyton Jones's avatar
      f17992a4
    • Simon Peyton Jones's avatar
      Make the location in TcLclEnv and CtLoc into a RealSrcSpan · d2b6e767
      Simon Peyton Jones authored
      Previously it was a SrcSpan, which can be an UnhelpulSrcSpan,
      but actually for TcLclEnv and CtLoc we always know it is
      a real source location, and it's good to make the types
      reflect that fact.
      
      There is a continuing slight awkwardness (not new with this
      patch) about what "file name" to use for GHCi code.  Current
      we say "<interactive>" which seems just about OK.
      d2b6e767
  2. 05 Jan, 2015 1 commit
  3. 03 Jan, 2015 4 commits
  4. 31 Dec, 2014 2 commits
    • Simon Peyton Jones's avatar
      When solving one Given from another, use the depth to control which way round · d8d00318
      Simon Peyton Jones authored
      See Note [Replacement vs keeping].
      
      There's a bit further to go with this change (to report unused givens).
      But it's already an improvement; see the latent bug described in the Note.
      d8d00318
    • Simon Peyton Jones's avatar
      Eliminate the final two calls to xCtEvidence · fd97d2a7
      Simon Peyton Jones authored
      I always found calls to TcCanonical.xCtEvidence hard to grok; and I
      found that we only had two left. This patch eliminates them, along
      with xCtEvidence, its accompanying comments, and the auxiliary
      XEvTerm type.
      
      The two remaining calls were these:
      
       * One was in newSCWorkFromFlavored, where we'd already done
         case-splitting for given/wanted/derived.  So inlining the xCtEvidence
         made the code simpler, clearer, and faster.
      
       * The other was in canTuple; here all of xCtEvidence's functionality
         was needed, but inlining again made a net gain in code size and
         clarity.
      fd97d2a7
  5. 30 Dec, 2014 5 commits
  6. 29 Dec, 2014 4 commits
  7. 28 Dec, 2014 5 commits
  8. 27 Dec, 2014 7 commits
  9. 25 Dec, 2014 1 commit
  10. 24 Dec, 2014 1 commit
    • rwbarton's avatar
      Fix linker interaction between Template Haskell and HPC (#9762) · 3e3aa925
      rwbarton authored
      Summary:
      I'm not really happy about perpetuating the hackish fix for #8696,
      but at least in the context of building with -fhpc, the performance
      cost should be negligible.
      
      I'm suspicious about PlainModuleInitLabel and the Windows stuff too,
      but I don't know what it does / can't test it (respectively) so I'll
      leave those alone for now.
      
      Hopefully out-of-process TH will save us from these hacks some day.
      
      The test is an adaptation of T8696. It's a bit more awkward since
      I couldn't think of a way to get cross-module tickbox references
      without optimizations (inlining), but ghci doesn't permit -O for
      some reason.
      
      Test Plan: harbormaster; validate
      
      Reviewers: austin
      
      Reviewed By: austin
      
      Subscribers: carter, thomie
      
      Differential Revision: https://phabricator.haskell.org/D583
      
      GHC Trac Issues: #9762
      
      Conflicts:
      	testsuite/tests/ghci/scripts/all.T
      3e3aa925