GitLab

This reverts commit da4687f6.

It's not entirely trivial to clean up the dead code this patch
introduced. In particular, when we see

```
case raiseIO# m s of
  s' -> e
```

we want to know that `e` is dead. For scrutinees that are properly
bottom (which we don't want to consider `raiseIO# m s` to be, this
is handled by rewriting `bot` to `case bot of {}`. But if we do
that for `raiseIO#`, we end up with

```
case raiseIO# m s of {}
```

which looks a lot like bottom and could confuse demand analysis.
I think we need to wait with this change until we have a more
complete story.

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie

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

Fixes #13508.

[skip ci]

Test Plan: Read it

Reviewers: austin

Subscribers: rwbarton, thomie

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

Fixes #13514.

Before this change we installed hp2ps both
to inplace/bin/ and ${prefix}/bin/

In both cases we added $(CrossCompilePrefix) as
a binary prefix. It's incorrect for inplace install
as none of inplace binaries are prefixed.

The change it to track 'hp2ps' as unprefixed binary.
$(CrossCompilePrefix) prefix is only added to the
installed shell wrapper.

Now 'hp2ps' is handled in a similar way to 'hpc' and
'ghc-pkg'.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

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

Previously these were considered to be framework failures, meaning that validate
would fail. For better or worse, Windows lacks a good number of metrics and I
don't see this changing any time soon. Let's consider these to be non-fatal.

This will make it a bit easier to maintain consistent output in the testsuite.

ghc-8.2 and master disagreed on the order of the instances. Normalise this
difference away.

Updates array submodule.

Summary:
To handle wired in packages, we must rewrite all occurrences
of unit ids like base-4.9.0.0 to base.  However, I forgot
to do this on unit ids that occurred in unit identifiers
passed via -instantiated-with.  This patch handles that case,
plus a test.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: bgamari, austin

Subscribers: rwbarton, thomie

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

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

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

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

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

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

Summary:
I observed a bug where if I modified the module which implemented
an hsig in another package, GHC would not recompile the signature
in this situation.

The root cause was that we were conflating modules from user
imports, and "system" module dependencies (from signature
merging and instantiation.) So this patch handles them separately.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: simonpj, bgamari, austin

Subscribers: rwbarton, thomie, snowleopard

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

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

We can sometimes produce much better code by deriving the
definition of `null` rather than using the default. For example,
given

    data SnocList a = Lin | Snoc (SnocList a) a

the default definition of `null` will walk the whole list, but of
course we can stop as soon as we see `Snoc`. Similarly, if a
constructor contains some other `Foldable` type, we want to use its
`null` rather than folding over the structure.

Partially fixes Trac #13280

Reviewers: austin, bgamari, RyanGlScott

Reviewed By: RyanGlScott

Subscribers: rwbarton, thomie

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

Similar to 'arm' 'aarch64' has working llvm codegen,
no need to fallback to unregisterised buld by default.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

Before this change attempt to build a crosscompiler
on registerised platform (--host=x86_64-pc-linux-gnu)
targeting UNREG platform failed:
    $ ./configure --target=ia64-unknown-linux-gnu

  utils/genapply/../../includes/stg/MachRegs.h:608:2: error:
     #error Cannot find platform to give register info for

The change is to check --target= for NCG availability,
not --host=.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie

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

Deriving null even helps for a simple list-like type,
presumably because we don't perform the static argument
transformation. Adding this test before the null deriving
patch should give a proper baseline.

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie

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

This was horribly, horribly wrong.

Test Plan: validate

Reviewers: angerman, austin, bgamari, erikd

Reviewed By: bgamari

Subscribers: rwbarton, thomie

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

Now that we throw an exception for heap overflow, we should only print
the heap overflow message in the main thread when the HeapOverflow
exception is caught, rather than as a side effect in the GC.

Stack overflows were already done this way, I just made heap overflow
consistent with stack overflow, and did some related cleanup.

Fixes broken T2592(profasm) which was reporting the heap overflow
message twice (you would only notice when building with profiling
libs enabled).

Test Plan: validate

Reviewers: bgamari, niteria, austin, DemiMarie, hvr, erikd

Reviewed By: bgamari

Subscribers: rwbarton, thomie

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

Similar to
  https://ghc.haskell.org/trac/ghc/ticket/13491
  https://phabricator.haskell.org/D3122

SIZEOF_HSINT and SIZEOF_VOID_P are sizes of
target platform. These values are usually
not correct when stage1 is built.

It means the code

```haskell
  newFastMutInt = IO $ \s ->
   case newByteArray# size s of { (# s, arr #) ->
   (# s, FastMutInt arr #) }
   where !(I# size) = SIZEOF_HSINT
```
would try to allocate only 4 bytes on 64-bit-host
targeting 32-bit system.

It does not matter in practice as newByteArray#
implementation rounds up passed value to host's
word size. But one day it might not.

To prevent this class of problems in compiler/
directory 'MachDeps.h' contents is hidden when
ghc-stage1 (-DSTAGE=1) is built.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

Reviewers: austin, rwbarton, simonmar, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

When GhcWithInterpreter=NO is set in mk/build.mk build
fails as:

    $ inplace/bin/dll-split compiler/stage2/build/.depend-v-dyn.haskell "DynFlags" ...
    Reachable modules from DynFlags out of date
    Please fix compiler/ghc.mk, or building DLLs on Windows may break (#7780)
    Extra modules: ByteCodeTypes InteractiveEvalTypes
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

This reduces peak memory usage by ~30% on my test case (DynFlags),
and (probably as a result of reduced GC work) decreases compilation
time by a few percent as well.

Also fix a bug in seqStrDmd so that demeand info is fully evaluated.

Reviewers: simonpj, austin, bgamari

Reviewed By: bgamari

Subscribers: dfeuer, thomie

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

* If the package flags haven't changed, don't do initPackages (which
  might take multiple seconds in extreme cases)

* Provide a way to change the log_action without invalidating the
  summary cache.

Test Plan: validate

Reviewers: niteria, bgamari, austin, erikd, ezyang

Reviewed By: bgamari

Subscribers: mpickering, rwbarton, thomie

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

There's no obvious reason to derive the definition of `showList`,
manually inlining the default definition. Let's just use
the default definition in the usual manner.

Garbage collect a few unused `RdrNames` from `PrelNames`:
`showList`, `showList__`, and `/=`.

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: RyanGlScott, rwbarton, thomie

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

Moritz Angermann reports mysterious rts crash:
  A: link: internal error: schedule: invalid what_next field
  A:     (GHC version 8.3.20170321 for arm_none_linux_android)

This change prints actual prev_what_next value.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

Unregisterised GHC can only use C as a target backend
(option used to be called -fvia-C). -fasm option was
ignored with a warhing, but not -fllvm.

jms noticed the failure when tried to use quick-cross
build flavour. quick-cross enables -fllvm in makefile.

  "inplace/bin/ghc-stage1" ... -fllvm
  ghc-stage1: panic! (the 'impossible' happened)
    (GHC version 8.0.2 for powerpc-unknown-linux):
          LlvmCodeGen.Ppr: Cross compiling without valid target info.

This change ignores -fllvm as well.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

It was expensive, as the simplifier runs for many iterations,
and probably not very useful.

Test Plan: harbormaster

Reviewers: austin, bgamari, dfeuer

Reviewed By: dfeuer

Subscribers: dfeuer, thomie

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

When GHCi tries to find a shared lib, it calls "gcc --print-file-name"
to ask gcc where to find it.  But since we're looking for libraries,
we're really using the linker here, not the C compiler, so we should be
respecting the values of -pgml and -optl rather than -pgmc and -optc.

Test Plan: validate

Reviewers: bgamari, niteria, austin, hvr, erikd

Reviewed By: bgamari

Subscribers: rwbarton, thomie

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

The Join points commit (8d5cf8bf) introduced a space leak
somewhere in the simplifier. The extra strictness added in this commit
fixes the leak. Unfortunately I don't really understand the details.

Unfortunately, the extra strictness appears to result in more overall
allocations in some cases, even while the peak heap size decreases in others.

Test Plan: harbormaster

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

In Core, Constraint should be considered fully equal to
TYPE LiftedRep, in all ways. Accordingly, coreView should
unwrap Constraint to become TYPE LiftedRep. Of course, this
would be a disaster in the type checker.

So, where previously we used coreView in both the type checker
and in Core, we now have coreView and tcView, which differ only
in their treatment of Constraint.

Historical note: once upon a past, we had tcView distinct from
coreView. Back then, it was because newtypes were unwrapped in
Core but not in the type checker. The distinction is back, but
for a different reason than before.

This had a few knock-on effects:

 * The Typeable solver must explicitly handle Constraint to ensure
   that we produce the correct evidence.

 * TypeMap now respects the Constraint/Type distinction

Finished by: bgamari

Test Plan: ./validate

Reviewers: simonpj, austin, bgamari

Reviewed By: simonpj

Subscribers: rwbarton, thomie

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

This small refactoring, provoked by comment:18 on Trac #13426,
makes it so that simplExprF never gets a (Type ty) expression to
simplify, which in turn means that calls to exprType on its argument
will always succeed.

No change in behaviour.

These checks, introduced in cea71418
hugely inflated build logs, which incapitated perf.haskell.org.

According to Richard, the checks are useless and wrong, and that Ben
plans to investigate.
(https://phabricator.haskell.org/rGHCcea7141851ce653cb20207da3591d09e73fa396d#64647)

Until that happens, I remove them from the code.