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

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

To test:
  * run `make clean` in utils/runghc
  * make sure inplace/bin doesn't contain runghc
  * set GhcWithInterpreter=NO in build.mk
  * run `make`
  * note that inplace/bin doesn't contain runghc

It won't be installed either, nor will runhaskell.

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

Running `make clean` inside `utils/runghc` now does:
    "rm" -rf utils/runghc/dist-install
    "rm" -rf inplace/bin/runghc
    "rm" -rf inplace/lib/bin/runghc

Instead of just:
    "rm" -rf utils/runghc/dist-install
    "rm" -rf inplace/lib/bin/runghc

I think this was just an oversight.

[skip ci]

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

There is no support for local variables inside `make` macros (defined
using the `define` keyword), see
[wiki:Building/Architecture/Idiom/Macros].

In this case `make show VALUE=INPLACE_WRAPPER` would print some bogus
value ("inplace/bin/mkUserGuidePart" actually, from the last BUILD_DIRS
entry in ghc.mk that calls shell-wrapper), and using that variable
somewhere might be a bug.

Test Plan:
I checked the rules directory with the following crude regexp, and this
seems the be the only real offender.

    grep -P '^[^ $#\t][^$]*[^+]=' rules/*

What it is supposed to do (from right to left):
  * look for variable assignments
  * but not updates (+=)
  * where the variable name doesn't contain any dollar signs
  * and the line doesn't start with whitespace or a comment

[skip ci]

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

Make sure $1_$2_PROG always gets assigned a value, even when cleaning.

The problem with not setting the variable becomes apparent when looking
at the following two lines of code:

```
  $1_$2_INPLACE = $$(INPLACE_LIB)/bin/$$($1_$2_PROG)
  $(call clean-target,$1,$2_inplace,$$($1_$2_INPLACE))
```

So running `make clean` in for example `utils/ghc-pkg` deletes
`inplace/lib/bin/` instead of `inplace/lib/bin/ghc-pkg`.

The offending code was introduced in commit
2b85372c.

There is one small implication. When cleaning before configure, the
variable $1_$2_PROG will now be assigned a slightly wrong value, because
exeext$3 isn't known yet. But I think that's ok, as no files have been
build yet, so it will just try to delete a slighly different nonexistent
file.

[skip ci]

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

Do what this comment was suggesting:

    "Ideally we'd like to have 'make -r' turned on by default, because
    that disables all the implicit rules, but there doesn't seem to be a
    good way to do that."

This change doesn't seem to have much effect on the time it takes to run
make. Apparently clearing .SUFFIXES was enough for that. But it does
make the output of `make -d` quite a bit shorter, which is nice.

Note: ghc.mk is always called indirectly, so no need to set .SUFFIXES or
MAKEFLAGS there again.

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

[skip ci]

[skip ci]

[skip ci]

This would happen when running `make clean` before running
`./configure`.

[skip ci]

[skip ci]

We only ever check if CLEANING=YES.

[skip ci]

To check if we're cleaning, always check the $CLEANING variable, instead
of sometimes $CLEANING, sometimes $MAKECMDGOALS.

[skip ci]

[skip ci]

Avoid unnecessary warnings.

[skip ci]

Remove the recently introduced `fast` synonym for `fasttest`, because in
the subdirectories `make fast` already means `make all FAST=YES`.

[skip ci]

[skip ci]

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

Rufflewind authored 9 years ago and Thomas Miedema committed 9 years ago

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

erdeszt authored 9 years ago and Thomas Miedema committed 9 years ago

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