GitLab

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

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: Austin Seipp <austin@well-typed.com>

Reviewed By: thomie, nomeata

Differential Revision: https://phabricator.haskell.org/D934

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

Summary:
The load was introduced a32d3e4d
to fix a bug where deprecations assumed that the name in question
had already had their interface loaded.  The new deprecation
code no longer makes this assumption and just loads the interface,
so this eager load is not necessary.

Verified that TH_reifyType2 continues to work.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: simonpj, austin

Subscribers: bgamari, thomie

Differential Revision: https://phabricator.haskell.org/D891

GHC Trac Issues: #10419

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

Summary:
Fixes T10446.

The following program

> g = static f

now produces only:

> ...: error
>    Not in scope: 'f'

Before it would also produce a complaint about 'f' not being a top-level
identifier.

Test Plan: validate

Reviewers: austin

Reviewed By: austin

Subscribers: bgamari, thomie, mboes

Differential Revision: https://phabricator.haskell.org/D906

GHC Trac Issues: #10446

Left in by c89bd681, and otherwise rather annoying during the build!
Signed-off-by: Austin Seipp <austin@well-typed.com>

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.

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)

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

Summary:
In the following code fragment

    let ls :: Int = undefined

the `::` is attached to the ls function as a whole, rather than to the
pattern on the LHS.

Test Plan: ./validate

Reviewers: hvr, austin

Reviewed By: austin

Subscribers: bgamari, thomie, mpickering

Differential Revision: https://phabricator.haskell.org/D883

GHC Trac Issues: #10396

Summary:
In the following code, the extra set of parens around the context end up
with detached annotations.

    {-# LANGUAGE PartialTypeSignatures #-}
    module ParensAroundContext where

    f :: ((Eq a, _)) => a -> a -> Bool
    f x y = x == y

Trac ticket #10354

It turns out it was the TupleTy that was the culprit.

This may also solve #10315

Test Plan: ./validate

Reviewers: hvr, austin, goldfire

Reviewed By: austin

Subscribers: goldfire, bgamari, thomie, mpickering

Differential Revision: https://phabricator.haskell.org/D868

GHC Trac Issues: #10354, #10315

Summary:
When parsing

    {-# LANGUAGE ScopedTypeVariables #-}

    extremumNewton :: forall tag. forall tag1.
                       tag -> tag1 -> Int
    extremumNewton = undefined

the parser creates nested HsForAllTy's for the two forall statements.

These get flattened into a single one in `HsTypes.mk_forall_ty`

This patch removes the flattening, so that API Annotations are not lost in the
process.

Test Plan: ./validate

Reviewers: goldfire, austin, simonpj

Reviewed By: simonpj

Subscribers: bgamari, mpickering, thomie, goldfire

Differential Revision: https://phabricator.haskell.org/D836

GHC Trac Issues: #10278, #10315, #10354, #10363

Thanks to Christiaan Baaj for spotting this.

Apparently my machine likes this commit, but Harbormaster does not?

This reverts commit b199536b.

This reverts commit b0b11ad9.

It apparently made Harbormaster sad.

When using GHCi, we explicitly reject optimization, because the
compilers optimization passes can introduce unboxed tuples, which the
interpreter is not able to handle. But this goes the other way too: using
GHCi on optimized code may cause the optimizer to float out breakpoints
that the interpreter introduces. This manifests itself in weird ways,
particularly if you as an API client use custom DynFlags to introduce
optimization in combination with HscInterpreted.

It turns out we weren't checking for consistent DynFlag settings when
doing `setSessionDynFlags`, as #10052 showed. While the main driver
handled it in `DynFlags` via `parseDynamicFlags`, we didn't check this
elsewhere.

This does a little refactoring to split out some of the common code, and
immunizes the various `DynFlags` utilities in the `GHC` module from this
particular bug. We should probably be checking other general invariants
too.

This fixes #10052, and adds some notes about the behavior in `GHC` and
`FloatOut`

As a bonus, expose `warningMsg` from `ErrUtils` as a helper since it
didn't exist (somehow).
Signed-off-by: Austin Seipp <austin@well-typed.com>

Reviewed By: edsko

Differential Revision: https://phabricator.haskell.org/D727

GHC Trac Issues: #10052

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

These behave like the count arguments of the gdb `up` and `down`
commands, allowing the user to quickly jump around in history.

Reviewed By: austin

Differential Revision: https://phabricator.haskell.org/D853

Since GHC requires at least LLVM 3.6, some of the special cases (for,
e.g., LLVM 2.8 or 2.9) in the LLVM CodeGen can be simply removed.

Reviewed By: rwbarton, austin

Differential Revision: https://phabricator.haskell.org/D884

GHC Trac Issues: #10074

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

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

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

When working on #10397, I noticed that "reorder" in
nativeCodeGen/seqBlocks took more than 60% of the time. With this
refactoring, it does not even show up in the profile any more. This
fixes #10422.

Differential Revision: https://phabricator.haskell.org/D893

This is an attempt to improve the situation described in #10397, where
the linear scan of possible candidates for commoning up is far too
expensive. There is (ever) more room for improvement, but this is a
start.

Differential Revision: https://phabricator.haskell.org/D892

This reverts multiple commits from Simon:

  - 04a484ea Test Trac #10359
  - a9ccd37a Test Trac #10403
  - c0aae6f6 Test Trac #10248
  - eb6ca851 Make the "matchable-given" check happen first
  - ca173aa3 Add a case to checkValidTyCon
  - 51cbad15 Update haddock submodule
  - 6e1174da Separate transCloVarSet from fixVarSet
  - a8493e03 Fix imports in HscMain (stage2)
  - a154944b Two wibbles to fix the build
  - 5910a1bc Change in capitalisation of error msg
  - 130e93aa Refactor tuple constraints
  - 8da785d5 Delete commented-out line

These break the build by causing Haddock to fail mysteriously when
trying to examine GHC.Prim it seems.

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

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.

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.

...following the constraint-tuple patch.

* There was interaction with the recent Safe Haskell change
* Haddock comoplained about constraint tuples defined but not used

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

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.

 * 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

The <$> operator is only available in the standard Prelude in
ghc 7.10 and later.
Signed-off-by: Erik 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

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.

Instances in Safe Inferred modules weren't marked being marked as coming
from a Safe module.