When user installs _native_ build ghc executable is renamed
from '$(libexec)/bin/ghc-stage<N>' to '$(libexec)/bin/ghc'.
But not on windows!

In case of _cross-compiler_ rename should happen only
for '$(libexec)/bin/ghc-stage<N>' runnable on non-windows
platform.

Before the change '$(libexec)/bin/ghc-stage<N>' rename happened
for any compiler not targeting windows.

After the patch rename also happens for '$(libexec)/bin/ghc-stage1'
cross-compiler built for linux targeting windows (Stage1Only=YES case).

Or on a concrete example:

   # host is x86_64-pc-linux-gnu
   $ ./configure --target=i686-w64-mingw32
   $ make install Stage1Only=YES

Before the change the layout was:
   - '$(libexec)/bin/ghc-stage1' was installed
   - bin/ghc contained 'exec $(libexec)/bin/ghc' # missing file!
After the change:
   - '$(libexec)/bin/ghc' was installed
   - bin/ghc contained 'exec $(libexec)/bin/ghc' # present file

Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

It's not a new behaviour. First it was introduced by
2d5372cf
("lower -O2 optimization down to -O1 on UNREG") to fix build
failure on unregisterised powerpc64.

This time I've noticed build failures on unregisterised ia64.

The change was accidentally reverted by commit
14d0f7f1
("Build system: Add stage specific SRC_HC_(WARNING_)OPTS)

The revert happened due to the following code rearrangement:

    ifeq "$(GhcUnregisterised)" "YES"
    GhcStage1HcOpts=
    GhcStage2HcOpts=
    GhcStage3HcOpts=
    endif

    GhcUnregisterised=@Unregisterised@

As a result 'ifeq' part has no effect.

The change moves 'ifeq' down to the very end of file
and adds a note it depends on the 'GhcUnregisterised' variable.

Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

Commit 66108864 reverted ability
to override 'dllwrap' and 'windres' paths when cross-compiling.

After this change (and a few libraries/Win32 patches) I was able
to build cross-compiler to windows:

    $ ./configure --target=i686-w64-mingw32 \
        DllWrap=i686-w64-mingw32-dllwrap \
        Windres=i686-w64-mingw32-windres

Later both 'dllwrap' and 'windres' should be derived from --target=
as we do now for 'CC', 'AR', 'NM' and others.

Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

niteria authored 7 years ago and Ben Gamari committed 7 years ago

Based on my quick search, we don't have a test
that verifies that we check the type family instances of
currently compiled module against direct or indirect
dependencies.

This adds two tests: for a direct dependency and
for an indirect dependency.

I also added a comment to make it clear what the 'Over'
test tests.

Other than completeness, it makes sense to have these
tests because if you look at
Note [The type family instance consistency story] in FamInsts
these cases are checked through different mechanisms.

Test Plan: new tests

Reviewers: simonmar, rwbarton, simonpj, austin, bgamari

Reviewed By: simonpj, bgamari

Subscribers: thomie

GHC Trac Issues: #13719

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

niteria authored 7 years ago and Ben Gamari committed 7 years ago

I expect to improve this, a testcase will ensure
it doesn't regress.

Test Plan: ./validate

Reviewers: simonmar, austin, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie

GHC Trac Issues: #13719

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

Rufflewind authored 7 years ago and Ben Gamari committed 7 years ago

Add "header" to GHC_COLORS and allow colors to be inherited from the
surroundings.

Test Plan: validate

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie

GHC Trac Issues: #13718

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

Herbert Valerio Riedel authored 7 years ago and Ben Gamari committed 7 years ago

When main module is listed on command line as a file, we should not
issue a warning about it. See Trac #13727

Reviewers: austin, bgamari, Yuras

Reviewed By: bgamari, Yuras

Subscribers: 23Skidoo, rwbarton, thomie

GHC Trac Issues: #13727

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

Kubo Kovac authored 7 years ago and Ben Gamari committed 7 years ago

got an error when using asan:
```
==1866689==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 16 byte(s) in 1 object(s) allocated from:
    #0 0x10640568 in malloc ??:?
    #1 0x154d867e in numa_bitmask_alloc .../numactl-2.0.8/libnuma_nosymve r.c:204
    #2 0x154d867e in numa_allocate_nodemask .../numactl-2.0.8/libnuma_nosymve r.c:724
    #3 0x154d867e in numa_get_mems_allowed .../numactl-2.0.8/libnuma_nosymve r.c:1141
    #4 0x10b54a45 in osNumaMask ...ghc-8.0.2/rts/posix/OSMem.c:59 8
```

Test Plan: compile, validate

Reviewers: simonmar, niteria, austin, bgamari, erikd

Reviewed By: bgamari

Subscribers: rwbarton, thomie

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

Ben Gamari authored 7 years ago and Ben Gamari committed 7 years ago

Test Plan: Validate

Reviewers: hvr, austin

Subscribers: rwbarton, thomie, erikd

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

Ben Gamari authored 7 years ago and Ben Gamari committed 7 years ago

Rebuild package.cache to ensure that it's newer than the package
database registration files, avoiding out-of-date cache warnings from
ghc-pkg. See #13375.

Test Plan: `make install`, run `ghc-pkg list`, look for out-of-date
cache warning

Reviewers: austin

Subscribers: rwbarton, thomie

GHC Trac Issues: #13375

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

Moritz Angermann authored 7 years ago and Ben Gamari committed 7 years ago

The llvm textual ir seems to have stayed sufficiently similar from llvm
3.9 to llvm 4.0, such that a simple bump is possible.

Reviewers: austin, hvr, bgamari, erikd

Reviewed By: bgamari, erikd

Subscribers: rwbarton, thomie, erikd

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

We need to use parentheses more when pretty-printing types with bang
patterns within constructors that use record syntax. Fixes #13699.

Test Plan: make test TEST=T13699

Reviewers: austin, bgamari, dfeuer

Reviewed By: dfeuer

Subscribers: dfeuer, rwbarton, thomie

GHC Trac Issues: #13699

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

`MIN_VERSION_pkg` was documented backwards. An important caveat
about initializing the Haskell runtime was buried in a footnote.
The documentation of `-dynamic` was (even more) confusing.

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie

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

Rufflewind authored 7 years ago and Ben Gamari committed 7 years ago

rwbarton pointed out that tab expansions can affect the column numbers
of subsequent characters, so a unstateful map + zip won't do.  This
commit hopefully fixes that.  It also adds a test for this particular
case.

Test Plan: validate

Reviewers: bgamari, rwbarton, austin

Reviewed By: bgamari

Subscribers: dfeuer, thomie

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

Ben Gamari authored 7 years ago and Ben Gamari committed 7 years ago

Test Plan: read it

Reviewers: dfeuer, austin, hvr, nomeata

Reviewed By: dfeuer, nomeata

Subscribers: nomeata, rwbarton, thomie

GHC Trac Issues: #13689

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

Douglas Wilson authored 7 years ago and Ben Gamari committed 7 years ago

This patch relates to Trac #8025

The goal here is to enable typechecking of packages that contain some
template haskell. Prior to this patch, compilation of a package with
-fno-code would fail if any functions in the package were called from
within a splice.

downsweep is changed to do an additional pass over the modules,
targetting any ModSummaries transitively depended on by a module that
has LangExt.TemplateHaskell enabled. Those targeted modules have
hscTarget changed from HscNothing to the default target of the platform.

There is a small change to the prevailing_target logic to enable this.

A simple test is added.

I have benchmarked with and without a patched haddock
(available:https://github.com/duog/haddock/tree/wip-no-explicit-th-compi
lation).  Running cabal haddock on the wreq package results in a 25%
speedup on my machine:

time output from patched cabal haddock:

real    0m5.780s
user    0m5.304s
sys     0m0.496s
time output from unpatched cabal haddock:

real    0m7.712s
user    0m6.888s
sys     0m0.736s

Reviewers: austin, bgamari, ezyang

Reviewed By: bgamari

Subscribers: bgamari, DanielG, rwbarton, thomie

GHC Trac Issues: #8025

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

Simplifier tick exhaustion is not necessarily "impossible", and
isn't even always a GHC bug, per se. Improve the error message.
Furthermore, the simplifier code has access to `IO`, so we can
throw a proper `IO` exception instead of panicking.

Reviewers: austin, bgamari, angerman

Reviewed By: angerman

Subscribers: angerman, rwbarton, thomie

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

Trac #13625 pointed out that in

   data X :: Y where Y :: X

we need 'Y' to be in scope (as APromotionErr) when dealing with
X's kind signature.  Previously we got a crash.

This patch simplifies the code as well as making it work.

We were simply failing to recognise all the free variables of an
IfaceDecl, notably the ones in the coercion of an IfUnpackCo.
Result: the dependency analysis got messed up, so that fingerprint
calculation went wrong.  Trac #13695 showed it up.

A test case is tricky but the fix is a solid one.

This just switches to using pattern matching rather than field
selectors, which I generally prefer.  No change in behaviour.

I was alerted to this by Trac #12468 and #11325.  We were treating
insolubles (and "hole" constraints are treated as insoluble)
inconsistently.  In some places we were carefully rewriting them
e.g. Note [Make sure that insolubles are fully rewritten] in
TcCanonical.  But in TcSimplify we weren't feeding them into
the solver.

As a result, "hole" constraints were not being rewritten, which
some users found confusing, and I think rightly so.

This patch also fixes a bug in TcSMonad.emitInsoluble, in which two
different "hole" constriants could be treated (bogusly) as duplicates,
thereby losing one.

Core allows non-recursive type-lets, thus

   let a = TYPE ty in ...

They are substituted away very quickly, but it's convenient for
some passes to produce them (rather than to have to substitute
immediately).

Trac #13708 tried the effect of not running the simplifer at all
(a rather bizarre thing to do, but still).  That showed that some
passes crashed because they always treated a let-bounder binder
as an Id.  This patch adds some easy fixes.

Summary:
Cabal internal libraries are implemented using a trick, where the 'name'
field in ghc-pkg registration file is munged into a new form to keep
each internal library looking like a distinct package to ghc-pkg and
other tools; e.g. the internal library q from package p is named
z-p-z-q.

Later, Cabal library got refactored so that we made a closer distinction
between these "munged" package names and the true package name of a
package.  Unfortunately, this is an example of a refactor for clarity in
the source code which ends up causing problems downstream, because the
point of "munging" the package name was to make it so that ghc-pkg and
similar tools transparently used MungedPackageName whereever they
previously used PackageName (in preparation for them learning proper
syntax for package name + component name).  Failing to do this meant
that internal libraries from the same package (but with different
names) clobber each other.

This commit search-replaces most occurrences of PackageName in
ghc-pkg and turns them into MungedPackageName. Otherwise there
shouldn't be any functional differenes.

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

Test Plan: validate

Reviewers: bgamari, austin

Subscribers: rwbarton, thomie

GHC Trac Issues: #13703

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

This patch fixes Trac #13705, by fixing a long-standing outright bug
in the pure unifier.  I'm surprised this hasn't caused more trouble
before now!

Edward implemented these functions, but they aren't
used any more.  Trac #13679

Dave Laing authored 7 years ago and Ben Gamari committed 7 years ago

Test Plan: validate

Reviewers: austin, bgamari, simonmar, mpickering

Reviewed By: mpickering

Subscribers: mpickering, rwbarton, thomie

GHC Trac Issues: #12610

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

This reverts commit 7fea7121.
It turns out that on a newly added MultiLayerModules test
case it gets very expensive to union the transitive module
sets while preserving determinism.

Fortunately, we can just sort to restore determinism
when converting imp_dep_mods to a list.

Test Plan: ./validate

Reviewers: simonmar, austin, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie

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

I'm optimizing a case that is well approximated by
multiple layers of modules where every module in a layer
imports all the modules in the layer below.

It turns out I regressed performance on such cases in 7fea7121.
I'm adding a test case to track improvements and prevent
future regressions.

Test Plan: ./validate

Reviewers: simonmar, austin, bgamari

Subscribers: rwbarton, thomie

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