1. 01 Jun, 2015 3 commits
    • Alan Zimmerman's avatar
      ApiAnnotations : strings in warnings do not return SourceText · e6191d1c
      Alan Zimmerman authored
      Summary:
      The strings used in a WARNING pragma are captured via
      
          strings :: { Located ([AddAnn],[Located FastString]) }
              : STRING { sL1 $1 ([],[L (gl $1) (getSTRING $1)]) }
          ..
      
      The STRING token has a method getSTRINGs that returns the original
      source text for a string.
      
      A warning of the form
      
          {-# WARNING Logic
                    , mkSolver
                    , mkSimpleSolver
                    , mkSolverForLogic
                    , solverSetParams
                    , solverPush
                    , solverPop
                    , solverReset
                    , solverGetNumScopes
                    , solverAssertCnstr
                    , solverAssertAndTrack
                    , solverCheck
                    , solverCheckAndGetModel
                    , solverGetReasonUnknown
                    "New Z3 API support is still incomplete and fragile: \
                    \you may experience segmentation faults!"
            #-}
      
      returns the concatenated warning string rather than the original source.
      
      This patch now deals with all remaining instances of getSTRING to bring
      in a SourceText for each.
      
      This updates the haddock submodule as well, for the AST change.
      
      Test Plan: ./validate
      
      Reviewers: hvr, austin, goldfire
      
      Reviewed By: austin
      
      Subscribers: bgamari, thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D907
      
      GHC Trac Issues: #10313
      e6191d1c
    • Austin Seipp's avatar
      compiler/specialise: shut match_co up a bit · f5b43ce1
      Austin Seipp authored
      This stray pprTrace is quite annoying and makes our build logs a bit
      bigger (hundreds of lines of occurrences), so we should probably just
      get rid of it. Kept under DEBUG for future brave hackers.
      Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
      
      Reviewed By: thomie, nomeata
      
      Differential Revision: https://phabricator.haskell.org/D934
      f5b43ce1
    • rwbarton's avatar
      In ghci linker, link against all previous temp sos (#10322) · a52f1444
      rwbarton authored
      The OS X dlopen() appears to only resolve undefined symbols in
      the direct dependencies of the shared library it is loading.
      
      Reviewed By: trommler, austin
      
      Differential Revision: https://phabricator.haskell.org/D852
      
      GHC Trac Issues: #10322
      a52f1444
  2. 28 May, 2015 1 commit
  3. 27 May, 2015 1 commit
    • Alan Zimmerman's avatar
      ApiAnnotations tweaks · c5911479
      Alan Zimmerman authored
      Summary:
      A collection of minor updates for the API Annotations.
      
      1. The annotations for the implicity parameter is disconnected in the
         following
      
          type MPI = ?mpi_secret :: MPISecret
      
      2. In the following, the annotation for one of the commas is disconeected.
      
          mkPoli = mkBila . map ((,,(),,()) <$> P.base <*> P.pos <*> P.form)
      
      3. In the following, the annotation for the parens becomes disconnected
      
          data MaybeDefault v where
              SetTo :: forall v . ( Eq v, Show v ) => !v -> MaybeDefault v
              SetTo4 :: forall v a. (( Eq v, Show v ) => v -> MaybeDefault v
                                                      -> a -> MaybeDefault [a])
      
      Test Plan: ./validate
      
      Reviewers: hvr, austin
      
      Reviewed By: austin
      
      Subscribers: bgamari, thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D901
      
      GHC Trac Issues: #10399
      c5911479
  4. 26 May, 2015 1 commit
  5. 23 May, 2015 1 commit
  6. 22 May, 2015 4 commits
    • Simon Peyton Jones's avatar
      Fix a huge space leak in the mighty Simplifier · 45d9a15c
      Simon Peyton Jones authored
      This long-standing, terrible, adn somewhat subtle bug was exposed
      by Trac #10370, thanks to Reid Barton's brilliant test case (comment:3).
      
      The effect is large on the Trac #10370 test.
      Here is what the profile report says:
      
      Before:
       total time  =       24.35 secs   (24353 ticks @ 1000 us, 1 processor)
       total alloc = 11,864,360,816 bytes  (excludes profiling overheads)
      
      After:
       total time  =       21.16 secs   (21160 ticks @ 1000 us, 1 processor)
       total alloc = 7,947,141,136 bytes  (excludes profiling overheads)
      
      The /combined/ effect of the tidyOccName fix, plus this one, is dramtic
      for Trac #10370.  Here is what +RTS -s says:
      
      Before:
        15,490,210,952 bytes allocated in the heap
         1,783,919,456 bytes maximum residency (20 sample(s))
      
        MUT     time   30.117s  ( 31.383s elapsed)
        GC      time   90.103s  ( 90.107s elapsed)
        Total   time  120.843s  (122.065s elapsed)
      
      After:
         7,928,671,936 bytes allocated in the heap
            52,914,832 bytes maximum residency (25 sample(s))
      
        MUT     time   13.912s  ( 15.110s elapsed)
        GC      time    6.809s  (  6.808s elapsed)
        Total   time   20.789s  ( 21.954s elapsed)
      
      - Heap allocation halved
      - Residency cut by a factor of more than 30.
      - ELapsed time cut by a factor of 6
      
      Not bad!
      
      The details
      ~~~~~~~~~~~
      The culprit was SimplEnv.mkCoreSubst, which used mapVarEnv to do some
      impedence-matching from the substitituion used by the simplifier to
      the one used by CoreSubst.  But the impedence-mactching was recursive!
      
        mk_subst tv_env cv_env id_env
          = CoreSubst.mkSubst in_scope tv_env cv_env (mapVarEnv fiddle id_env)
      
        fiddle (DoneEx e)          = e
        fiddle (DoneId v)          = Var v
        fiddle (ContEx tv cv id e) = CoreSubst.substExpr (mk_subst tv cv id) e
      
      Inside fiddle, in the ContEx case, we may do another whole level of
      fiddle.  And so on.  Moreover, UniqFM (which is built on Data.IntMap) is
      strict, so the fiddling is done eagerly.  I didn't wok through all the
      details but the result is a gargatuan blow-up of entirely unnecessary work.
      
      Laziness would make this go away, I think, but I don't want to mess
      with IntMap.  And in any case, the impedence matching is a royal pain.
      
      In the end I simply ceased trying to use CoreSubst.substExpr in the
      simplifier, and instead just use simplExpr.  That does mean bit of
      duplication; e.g.  new code for simplRules.  But it's not a big deal
      and it's far more direct and easy to reason about.
      
      A bit of knock-on refactoring:
      
       * Data type ArgSummary moves to CoreUnfold.
      
       * interestingArg moves from CoreUnfold to SimplUtils, and gets a
         SimplEnv argument which can be used when we encounter a variable.
      
       * simplLamBndrs, addBndrRules move from SimplEnv to Simplify
         (because they now calls simplUnfolding, simplRules resp)
      
       * SimplUtils.substExpr, substUnfolding, mkCoreSubst die completely
      
       * In Simplify some several functions that were previously pure
         substitution-based functions are now monadic:
           - addBndrRules, simplRule
           - addCoerce, add_coerce in simplCast
      
       * In case 2c of Simplify.rebuildCase, there was a pretty disgusting
         expression-substitution taking place for 'rhs'; and we really don't
         want to make that monadic becuase 'rhs' can be big.
         Solution: reduce the arity of the rules for seq.
         See Note [User-defined RULES for seq] in MkId.
      45d9a15c
    • Simon Peyton Jones's avatar
      Fix quadratic behaviour in tidyOccName · c89bd681
      Simon Peyton Jones authored
      In the test program from comment:3 of Trac #10370, it turned out
      that 25% of all compile time was going in OccName.tidyOccName!
      
      It was all becuase the algorithm for finding an unused OccName
      had a quadratic case.
      
      This patch fixes it.  THe effect is pretty big:
      
      Before:
      	total time  =       34.30 secs   (34295 ticks @ 1000 us, 1 processor)
      	total alloc = 15,496,011,168 bytes  (excludes profiling overheads)
      
      After
      	total time  =       25.41 secs   (25415 ticks @ 1000 us, 1 processor)
      	total alloc = 11,812,744,816 bytes  (excludes profiling overheads)
      c89bd681
    • Simon Peyton Jones's avatar
      Reduce magic for seqId · eae703aa
      Simon Peyton Jones authored
      An upcoming commit means that the RULES for 'seq' get only
      one value arg, not two.  This patch prepares for that by
      
      - reducing the arity of seq's built-in rule, to take one value arg
      - making 'seq' not inline on the LHS of RULES
      - and removing the horrid un-inlining in DsBinds.decomposeRuleLhs
      eae703aa
    • Simon Peyton Jones's avatar
      White space layout only · 369dd0c6
      Simon Peyton Jones authored
      369dd0c6
  7. 21 May, 2015 3 commits
  8. 20 May, 2015 1 commit
  9. 19 May, 2015 6 commits
  10. 18 May, 2015 4 commits
    • Simon Peyton Jones's avatar
      Make the "matchable-given" check happen first · 228ddb95
      Simon Peyton Jones authored
      This change makes the matchable-given check apply uniformly to
           - constraint tuples
           - natural numbers
           - Typeable
      as well as to vanilla class constraints.
      
      See Note [Instance and Given overlap] in TcInteract
      228ddb95
    • Simon Peyton Jones's avatar
      Refactor tuple constraints · ffc21506
      Simon Peyton Jones authored
      Make tuple constraints be handled by a perfectly ordinary
      type class, with the component constraints being the
      superclasses:
          class (c1, c2) => (c2, c2)
      
      This change was provoked by
      
        #10359  inability to re-use a given tuple
                constraint as a whole
      
        #9858   confusion between term tuples
                and constraint tuples
      
      but it's generally a very nice simplification. We get rid of
       -  In Type, the TuplePred constructor of PredTree,
          and all the code that dealt with TuplePreds
       -  In TcEvidence, the constructors EvTupleMk, EvTupleSel
      
      See Note [How tuples work] in TysWiredIn.
      
      Of course, nothing is ever entirely simple. This one
      proved quite fiddly.
      
      - I did quite a bit of renaming, which makes this patch
        touch a lot of modules. In partiuclar tupleCon -> tupleDataCon.
      
      - I made constraint tuples known-key rather than wired-in.
        This is different to boxed/unboxed tuples, but it proved
        awkward to have all the superclass selectors wired-in.
        Easier just to use the standard mechanims.
      
      - While I was fiddling with known-key names, I split the TH Name
        definitions out of DsMeta into a new module THNames.  That meant
        that the known-key names can all be gathered in PrelInfo, without
        causing module loops.
      
      - I found that the parser was parsing an import item like
            T( .. )
        as a *data constructor* T, and then using setRdrNameSpace to
        fix it.  Stupid!  So I changed the parser to parse a *type
        constructor* T, which means less use of setRdrNameSpace.
      
        I also improved setRdrNameSpace to behave better on Exact Names.
        Largely on priciple; I don't think it matters a lot.
      
      - When compiling a data type declaration for a wired-in thing like
        tuples (,), or lists, we don't really need to look at the
        declaration.  We have the wired-in thing!  And not doing so avoids
        having to line up the uniques for data constructor workers etc.
        See Note [Declarations for wired-in things]
      
      - I found that FunDeps.oclose wasn't taking superclasses into
        account; easily fixed.
      
      - Some error message refactoring for invalid constraints in TcValidity
      
      - Haddock needs to absorb the change too; so there is a submodule update
      ffc21506
    • Simon Peyton Jones's avatar
      Delete commented-out line · 76024fdb
      Simon Peyton Jones authored
      76024fdb
    • Joachim Breitner's avatar
      CmmCommonBlockElim: Improve hash function · 73f836f5
      Joachim Breitner authored
      Previously, the hash function used to cut down the number of block
      comparisons did not take local registers into account, causing far too
      many similar, but different bocks to be considered candidates for the
      (expensive!) comparision.
      
      Adding register to the hash takes CmmCommonBlockElim's share of the
      runtime of the example in #10397 from 17% to 2.5%, and eliminates all
      unwanted hash collisions.
      
      This patch also replaces the fancy trie by a plain Data.Map. It turned
      out to be not performance critical, so this simplifies the code.
      
      Differential Revision: https://phabricator.haskell.org/D896
      73f836f5
  11. 16 May, 2015 2 commits
  12. 14 May, 2015 1 commit
  13. 13 May, 2015 8 commits
    • Simon Peyton Jones's avatar
      Make the "matchable-given" check happen first · eb6ca851
      Simon Peyton Jones authored
      This change makes the matchable-given check apply uniformly to
           - constraint tuples
           - natural numbers
           - Typeable
      as well as to vanilla class constraints.
      
      See Note [Instance and Given overlap] in TcInteract
      eb6ca851
    • Simon Peyton Jones's avatar
      Add a case to checkValidTyCon · ca173aa3
      Simon Peyton Jones authored
      Apparently when Haddock'ing, we check GHC.Prim.
      So checkValidTyCon must not crash when dealing with
      PrimTyCons; and it was doing so in dataConStupidTheta.
      
      The fix is easy, but I'm puzzled about why Haddock needs to
      typecheck GHC.Prim.
      ca173aa3
    • Simon Peyton Jones's avatar
      Separate transCloVarSet from fixVarSet · 6e1174da
      Simon Peyton Jones authored
      I wasn't clear about the distinction before, and that led to a bug
      when I refactored FunDeps.oclose to use transCloVarSet; it should
      use fixVarSet.
      6e1174da
    • Simon Peyton Jones's avatar
      Fix imports in HscMain (stage2) · a8493e03
      Simon Peyton Jones authored
      a8493e03
    • Simon Peyton Jones's avatar
      Two wibbles to fix the build · a154944b
      Simon Peyton Jones authored
      ...following the constraint-tuple patch.
      
      * There was interaction with the recent Safe Haskell change
      * Haddock comoplained about constraint tuples defined but not used
      a154944b
    • Simon Peyton Jones's avatar
      Refactor tuple constraints · 130e93aa
      Simon Peyton Jones authored
      Make tuple constraints be handled by a perfectly ordinary
      type class, with the component constraints being the
      superclasses:
          class (c1, c2) => (c2, c2)
      
      This change was provoked by
      
        #10359  inability to re-use a given tuple
                constraint as a whole
      
        #9858   confusion between term tuples
                and constraint tuples
      
      but it's generally a very nice simplification. We get rid of
       -  In Type, the TuplePred constructor of PredTree,
          and all the code that dealt with TuplePreds
       -  In TcEvidence, the constructors EvTupleMk, EvTupleSel
      
      See Note [How tuples work] in TysWiredIn.
      
      Of course, nothing is ever entirely simple. This one
      proved quite fiddly.
      
      - I did quite a bit of renaming, which makes this patch
        touch a lot of modules. In partiuclar tupleCon -> tupleDataCon.
      
      - I made constraint tuples known-key rather than wired-in.
        This is different to boxed/unboxed tuples, but it proved
        awkward to have all the superclass selectors wired-in.
        Easier just to use the standard mechanims.
      
      - While I was fiddling with known-key names, I split the TH Name
        definitions out of DsMeta into a new module THNames.  That meant
        that the known-key names can all be gathered in PrelInfo, without
        causing module loops.
      
      - I found that the parser was parsing an import item like
            T( .. )
        as a *data constructor* T, and then using setRdrNameSpace to
        fix it.  Stupid!  So I changed the parser to parse a *type
        constructor* T, which means less use of setRdrNameSpace.
      
        I also improved setRdrNameSpace to behave better on Exact Names.
        Largely on priciple; I don't think it matters a lot.
      
      - When compiling a data type declaration for a wired-in thing like
        tuples (,), or lists, we don't really need to look at the
        declaration.  We have the wired-in thing!  And not doing so avoids
        having to line up the uniques for data constructor workers etc.
        See Note [Declarations for wired-in things]
      
      - I found that FunDeps.oclose wasn't taking superclasses into
        account; easily fixed.
      
      - Some error message refactoring for invalid constraints in TcValidity
      130e93aa
    • Simon Peyton Jones's avatar
      Delete commented-out line · 8da785d5
      Simon Peyton Jones authored
      8da785d5
    • Austin Seipp's avatar
      Revert D727 · 8764a7e8
      Austin Seipp authored
      This caused print007 to fail, so I guess I botched this more than I
      thought. This is a combination of reverting:
      
        "Fix build breakage from 9736c042", commit f35d621d.
        "compiler: make sure we reject -O + HscInterpreted", commit 9736c042.
      8764a7e8
  14. 12 May, 2015 4 commits
    • Zejun Wu's avatar
      Fix weird behavior of -ignore-dot-ghci and -ghci-scipt · f5188f3a
      Zejun Wu authored
       * Make `-ghci-script` be executed in the order they are specified;
       * Make `-ignore-dot-ghci` only ignores the default .ghci files but
         still execute the scripts passed by `-ghci-script`.
      
      Reviewed By: simonmar, austin
      
      Differential Revision: https://phabricator.haskell.org/D887
      
      GHC Trac Issues: #10408
      f5188f3a
    • Erik de Castro Lopo's avatar
      Use fmap instead of <$> (Fixes #10407) · c119a802
      Erik de Castro Lopo authored
      The <$> operator is only available in the standard Prelude in
      ghc 7.10 and later.
      Signed-off-by: Erik de Castro Lopo's avatarErik de Castro Lopo <erikd@mega-nerd.com>
      
      Test Plan: build with ghc-7.6
      
      Reviewers: dterei, ezyang, austin
      
      Subscribers: bgamari, thomie
      
      Differential Revision: https://phabricator.haskell.org/D886
      
      GHC Trac Issues: #10407
      c119a802
    • David Terei's avatar
      New handling of overlapping inst in Safe Haskell · 4fffbc34
      David Terei authored
      We do much better now due to the newish per-instance flags. Rather than
      mark any module that uses `-XOverlappingInstances`,
      `-XIncoherentInstances` or the new `OVERLAP*` pragmas as unsafe, we
      regard them all as safe and defer the check until an overlap occurs.
      
      An type-class method call that involves overlapping instances is
      considered _unsafe_ when:
      
      1) The most specific instance, Ix, is from a module marked `-XSafe`
      2) Ix is an orphan instance or a MPTC
      3) At least one instance that Ix overlaps, Iy, is:
         a) from a different module than Ix
         AND
         b) Iy is not marked `OVERLAPPABLE`
      
      This check is only enforced in modules compiled with `-XSafe` or
      `-XTrustworthy`.
      
      This fixes Safe Haskell to work with the latest overlapping instance
      pragmas, and also brings consistent behavior. Previously, Safe Inferred
      modules behaved differently than `-XSafe` modules.
      4fffbc34
    • David Terei's avatar
      Fix safe haskell bug: instances in safe-inferred · eecef173
      David Terei authored
      Instances in Safe Inferred modules weren't marked being marked as coming
      from a Safe module.
      eecef173