GitLab

Summary:
RnEnv contains functions which convertn RdrNames into Names.

RnUnbound contains helper functions for reporting and creating
unbound variables.

RnFixity contains code which maintains the fixity environent
whilst renaming.

RnUtils contains the other stuff in RnEnv.

Reviewers: austin, goldfire, bgamari

Subscribers: goldfire, rwbarton, thomie, snowleopard

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

iOS at least since iOS8 (we are currently at iOS10.3), allows for
dynamic libaries, hence any artificail restriction on dyanmic
libraries should be lifted.

Please ping me with any iOS related issues that should potentially
resurface.  The iOS toolchain has considerably changed over the
years, and I'm willing to drop work arounds in good faith.

Reviewers: bgamari, austin

Reviewed By: bgamari

Subscribers: rwbarton, thomie

GHC Trac Issues: #13559, #7722

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

Reviewers: austin, hvr, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie

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

Reviewers: bgamari, austin, erikd, simonmar, rwbarton

Reviewed By: bgamari, rwbarton

Subscribers: rwbarton, thomie

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

When doing this I noticed a horrible amount of duplication between
lookupSubBndrOcc and lookupExportChild (which I am responsible for).
I opened #13545 to keep track of this.

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie

GHC Trac Issues: #13528

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

It told me to use -fno-suppress-ticks, but it should have been
-dno-suppress-ticks.

Test Plan: tested -dppr-ticks and -frewrite-rules manually

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

DYNAMIC_GHC_PROGRAMS and GhcDynamic both tried to control whether
the ghc binary was built as a dynamic executable, with confusing
results. In particular, setting GhcDynamic=NO has no effect on
systems where DYNAMIC_GHC_PROGRAMS defaults to YES.

DYNAMIC_GHC_PROGRAMS is more fully-featured (it ensures that the
correct flavor of the libraries is built, for example) so let's
keep it and remove GhcDynamic to reduce confusion.

This effectively reverts commit 3c6190b0.

Test Plan: tested locally; harbormaster

Reviewers: simonmar, austin, bgamari

Reviewed By: bgamari

Subscribers: thomie, snowleopard

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

Reviewers: austin, erikd

Reviewed By: erikd

Subscribers: rwbarton, thomie, erikd

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

Test Plan: Test on x86 and x86_64

Reviewers: duncan, trofi, simonmar, tibbe, hvr, austin, rwbarton,
bgamari

Reviewed By: duncan

Subscribers: Phyx, DemiMarie, rwbarton, thomie

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

unless (not ..) -> when

Remove unused getLookupOccRn

Remove lookupGreRn2

It was only called in one place in a very strange way. It is easier
to just use lookupGreRn which has nearly the same implementation and
then directly call `unboundName`.

Remove unused function mapFvRnCPS

Remove unused functions bindLocatedLocalsRn and bindLocatedLocalsFV

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie

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

This fixes Trac #13558, by making App and Let behave
consistently; see Note [Arguments and let-bindings exprIsCheapX]

I renamed the mysterious exprIsOk to exprIsCheapX.  (The "X"
is because it is parameterised over a CheapAppFun.)

We were failing to float a nested binding
   x :: Addr# = "foo"#
to top level, even though we /were/ floating string
literals themselves.  A small oversight, easily fixed.

I realised (Trac #13543) that we can improve demand analysis for
join point quite straightforwardly.

The idea is explained in
    Note [Demand analysis for join points]
in DmdAnal

When doing type-in-type, Richard introduce some substantial
complications in CoreFVs, gathering types and free variables
of type.  In Trac #13160 we decided that this complication was
unnecessary, so this patch removes it.

Unfortnately I then fell down a twisty rabbit hole.  Roughly:

* An apparently-innocuous change in the AnnApp case of
  fiExpr made the fuction a little bit stricter, so we ended
  up peering into the arguments when we didn't before (namely
  when there are no bindings being floated inwards).  I've
  rejigged it so that it's not fragile any more.

* Peering into the arguments was sometimes expensive, becuase
  exprIsExpandable can be expensive because it looks deeply into
  the expression.

* The combination of the two led to a non-linear explosion
  of work when the argument of a function is a deeep nest
  of constructors.  This bug has been lurking for ages.

  I solved it by replacing exprIsExpandable with exprIsHNF
  + exprIsTrivial; see Note [noFloatInto considerations]

* The code around floating case-expressions turned out to be
  very delicate, because can_fail primops (which we want to
  float inwards) can't be floated outwards; so we have to be
  careful never to float them too far. Note [Floating primops]
  has the details

* I ended up refactoring some rather opaque code in
  sepBindsByDropPoint.

Working all this out meant that I rewrote quite a bit of
code, so it's now a reasonably substantial patch.  But it's
a net improvement.

Reviewers: rwbarton, bgamari, austin, erikd, simonmar, trofi

Reviewed By: trofi

Subscribers: trofi, thomie

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

Reviewers: bgamari, austin, erikd, simonmar, rwbarton

Reviewed By: rwbarton

Subscribers: rwbarton, thomie

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

With the introduction of -fexternal-interpreter we are
now able to compile template haskell via an extern iserv process.

This however is restricted to the same host, and can therefore
not be used with crosscompilers where the iserv slave process
needs to run on a different machine than the cross compiling
haskell compiler.

This diff breaks up iserv into a library and the iserv-bin binary.
It also introduces the iserv-proxy, a proxy instance that the
haskell compiler can talk to, and which forwards the calls
to the iserv slave on a different machine, as well as providing
some extra functionarily (sending files that are not available
on the machine the slave runs on), as well as forwarding from
the slave to the haskell compiler, when the slave needs to
interrogate the haskell compiler.

The iserv library now also exports the startSlave function to be
called by the application that implements the slave on the target.

The simplest such app would probably look something like:

```
extern void startServ(bool, const char *);

int main(int argc, char * argv[]) {
  hs_init(NULL, NULL);
  startServ(false,"/tmp");
  while(1);
}
```

Special thanks to Shea Levy for the first draft of the iserv-remote,
from which I took some inspiration.

The `Buildable` flags are due to ghc-cabal not being able to build
more than a single target.  Please note that only the stock iserv-bin
is supposed to be built *with* ghc.  The library and proxy are supposed
to be built outside of ghc.  Yet I believe that this code should live
together with iserv.

Reviewers: simonmar, ezyang, goldfire, austin, rwbarton, bgamari

Reviewed By: simonmar

Subscribers: luite, ryantrinkle, shlevy, thomie

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

- Mention that the read end is an `MVar`, so fairness guarantees are
  inherited.

- Mention that it can throw `BlockedIndefinitelyOnMVar` exception.

Reviewers: austin, hvr, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie

GHC Trac Issues: #5466

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

which counts allocations instead of observing recomputation directly.

as they might be marked as one-shot, and suddenly we’d evaluate them
multiple times. This came up in #13536 (test cases included).

The solution was layed out by SPJ in ticket:13536#comment:12.

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

as discussed in #13479.

Fix a regression in the pretty-printed code for -ddump-splices, which regressed
since 8.0.

Closes trac issue #13550

In navive build case it does not matter much if we build
'unlit' and 'hp2ps' tools with ghc-stage0 or ghc-stage1:
both GHCs are native compilers and both tools are written
in C (have no haskell code).

But in cross-case the difference is substantial:
In Stag1Only=YES case we need to install native tools built
by ghc-stage0/${host}-cc.
In Stag1Only=NO  case we need to install cross-built tools
built by ghc-stage1/${target}-cc.

Before this change GHC did not have a rule to build cross-built
'unlit' and 'hp2ps'.

The change adds cross-built 'unlit' and 'hp2ps' as 'dist-install'
targets.

'inplace/lib/bin/unlit.bin' target is unchanged and still contains
native binary.

As a result this change allows cross-building and packaging whole
GHC for target platform!
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

When cross-built GHC is being installed one of
latest steps is to register installed libraries
with 'ghc-pkg'.

GHC uses freshly installed 'ghc-pkg' and 'ghc-stage2'
for that.

Tested as:
    ./configure --target=aarch64-unknown-linux-gnu
    make install DESTDIR=$(pwd)/__s2 STRIP_CMD=:

Before the change install failed on ghc-pkg execution phase:

    ".../ghc-cross/__s2/usr/local/lib/ghc-8.3.20170406/bin/ghc-pkg" \
        --force \
        --global-package-db \
        ".../ghc-cross/__s2/usr/local/lib/ghc-8.3.20170406/package.conf.d" \
        update rts/dist/package.conf.install
    /bin/sh: .../ghc-cross/__s2/usr/local/lib/ghc-8.3.20170406/bin/ghc-pkg: \
        No such file or directory

To avoid breakage we use 'ghc' and 'ghc-pkg' built by stage0.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

Test Plan: run 'make install' on stage2 crosscompiler

Reviewers: rwbarton, austin, bgamari

Subscribers: thomie, snowleopard

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

This patch fixes Trac #13468, and at the same time makes the
code simpler and more uniform.  In particular, I've eliminated
the awkward conflict between the old built-in rule for seq
(which elimianted a cast), and the desire to make case scrutinse
a data type by doing type-family reduction (which adds a cast).

Nice.

When Stage1Only=YES install mode is used one of rare tools
that lack $(CrossCompilePrefix) prefix are 'runghc' and 'ghci'.

This causes file collisions when multiple GHC crosscompilers
are installed in system.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

Part of e13419c5 was accidentally lost during a rebase. This commit
adds the missing change, along with some more improvements
regarding where we do and don't use `seqType`.

Also include a comment about where the space leak showed up
and a Note explaining the strategy being used here.

Test Plan: harbormaster, plus local testing on DynFlags

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

The Harbormaster build seems to slightly disagree with my local build machine on
a few of these. In the case of `haddock.compiler` the difference is nearly an
order of magnitude. Odd.

x87's transcendental instructions are terribly imprecise and fail this test.
Moreover, we really ouch to enable -mse2 on i386 by default as it is nearly
universally supported at this point. See #13540.

Commit 2b64e926 (#13135) ended
up fixing #13538 as well. Let's add a regression test so that it stays
fixed.

Test Plan: make test TEST=T13538

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie

GHC Trac Issues: #13538

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

This reverts commit 03c7dd09 and fixes
the coercions.

In the implementation of WarnSimplifiableClassConstraints, be
less aggressive about reporting a problem. We were complaining
about a "fragile" case that in fact was not fragile.

See Note [Simplifiable given constraints] in TcValidity.

This fixes Trac #13526.