GitLab

Unbreak the build.

Summary:
See https://mail.haskell.org/pipermail/libraries/2015-April/025480.html
for the proposal and discussion
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: austin

Subscribers: bgamari, thomie

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

Summary:
This applies a patch from Reid Barton and Sylvain Henry, which fix a
disasterous infinite loop when iconv fails to load locale files, as
specified in #10298.

The fix is a bit of a hack but should be fine - for the actual reasoning
behind it, see `Note [Disaster and iconv]` for more info.

In addition to this fix, we also patch up the IO Encoding utilities to
recognize several variations of the 'ASCII' encoding (including its
aliases) directly so that GHC can do conversions without iconv. This
allows a static binary to sit in an initramfs.
Authored-by: Reid Barton <rwbarton@gmail.com>
Authored-by: Sylvain Henry <hsyl20@gmail.com>
Signed-off-by: Austin Seipp <austin@well-typed.com>

Test Plan: Eyeballed it.

Reviewers: rwbarton, hvr

Subscribers: bgamari, thomie

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

GHC Trac Issues: #10298, #7695

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

This should fix the testsuite driver on Windows using the MinGW tools
with a native build of Python.

MinGW automagically converts MinGW-style paths (e.g.
'/c/programs/ghc/bin/ghc') into ordinary Windows paths (e.g.
'C:/programs/ghc/bin/ghc') when a native Windows program is invoked. But
it doesn't do so when those paths are wrapped with a pair of escaped
double quotes.

The fix is to not call `eval` on the paths in Python, which let's us use
one less pair of quotes, and makes MinGW happy.

Reviewers: Rufflewind, austin

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

Rewrite config/ghc to use getStdout (which use subprocess.Popen) instead
of os.popen, which is deprecated; this also avoids the use of shell

Also:
* Move getStdout to driver/testutil.py so both config/ghc and
  driver/runtests.py can use it

* Remove support for Python below 2.4, which doesn't have subprocess

Reviewed By: thomie

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

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

When generating a haddock .t file for a library, don't save it in the
`dist-install/doc` directory for that library, as then it gets copied to
the installation directory during `make install` by `ghc-cabal copy`.
Instead, save it a few directories up; putting it next to
`haddock-prologue.txt` seemed appropriate.

Test Plan: run `make` in `tests/perf/haddock`.

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

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

Summary: Add -fobject-code to StaticPointers tests in ghci.

Test Plan: validate

Reviewers: austin

Reviewed By: austin

Subscribers: bgamari, thomie, mboes

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

Signed-off-by: erdeszt <erdeszt@gmail.com>

Reviewed By: bgamari, thomie

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

[skip ci]

The following tests would result in framework failures when using a ghc
build with HADDOCK_DOCS=NO in mk/build.mk or mk/validate.mk:

  * haddock.Cabal
  * haddock.base
  * haddock.compiler

Test Plan: run make in tests/perf/haddock

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

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

Simon apparently forgot this it seems.
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.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Fixes Trac #10430.

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

This reverts commit b199536b.

As Reid mentioned in a comment on D894, the case fixed by this revision
likely isn't really correct, because old ARM binaries could run on newer
machines, meaning we need to detect at runtime whether we need a proper
barrier.

But in the mean time, this actually stops the build from failing - which
is better off. So we'll just remember this when we fix it in the future.
Signed-off-by: Austin Seipp <austin@well-typed.com>

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 fixes the documentation for -Wall.
As was done previously it leaves out deprecated flags and also
fwarn-safe and fwarn-unsafe. I don't know
if that was intended or not. -fwarn-safe and fwarn-unsafe are
not mentioned on the warnings page at all instead they are
mentioned in the safe haskell section.

Reviewed By: austin

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

GHC Trac Issues: #10386

Module C imports a from Module A and b from module B. B does not
import anything from A. So if ld is configured to drop DT_NEEDED
tags for libraries it does not depend on no DT_NEEDED tag for the
temporary shared object containing module A is recorded in the temp
SO containing module B. This leads to an undefined symbol when
linking the temp SO for module C.

Fixes #10110.

Reviewed By: austin

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

GHC Trac Issues: #10110

Assuming there is no real SMP systems on these CPUs
I've added only compiler barrier (otherwise write_barrier
and friends need to be fixed as well).

Patch also fixes build breakage reported in #10244.
Signed-off-by: Sergei Trofimovich <siarheit@google.com>

Reviewers: rwbarton, nomeata, austin

Reviewed By: nomeata, austin

Subscribers: bgamari, thomie

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

GHC Trac Issues: #10244

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