This reverts commit 0440af6a.
Unfortunately this breaks on Windows for tiresome reasons. I'll need to
reevaluate this.

Triggered by the changes in #13677, I ended up doing a bit of
refactoring in type pretty-printing.

* We were using TyOpPrec and FunPrec rather inconsitently, so
  I made it consisent.

* That exposed the fact that we were a bit undecided about whether
  to print
     a + b -> c + d   vs   (a+b) -> (c+d)
  and similarly
     a ~ [b] => blah  vs   (a ~ [b]) => blah

  I decided to make TyOpPrec and FunPrec compare equal
  (in BasicTypes), so (->) is treated as equal precedence with
  other type operators, so you get the unambiguous forms above,
  even though they have more parens.

  We could readily reverse this decision.
  See Note [Type operator precedence] in BasicTypes

* I fixed a bug in pretty-printing of HsType where some
  parens were omitted by mistake.

IfaceType.hs-boot and ToIface.hs-boot were bigger than they
needed to be, so I'm shrinking them.

The big change here is to fix an outright bug in flattening of Givens,
albeit one that is very hard to exhibit.  Suppose we have the constraint
    forall a. (a ~ F b) => ..., (forall c. ....(F b)...) ...

Then
 - we'll flatten the (F) b to a fsk, say  (F b ~ fsk1)
 - we'll rewrite the (F b) inside the inner implication to 'fsk1'
 - when we leave the outer constraint we are suppose to unflatten;
   but that fsk1 will still be there
 - if we re-simplify the entire outer implication, we'll re-flatten
   the Given (F b) to, say, (F b ~ fsk2)
Now we have two fsks standing for the same thing, and that is very
wrong.

Solution: make fsks behave more like fmvs:
 - A flatten-skolem is now a MetaTyVar, whose MetaInfo is FlatSkolTv
 - We "fill in" that meta-tyvar when leaving the implication
 - The old FlatSkol form of TcTyVarDetails is gone completely
 - We track the flatten-skolems for the current implication in
   a new field of InertSet, inert_fsks.

See Note [The flattening story] in TcFlatten.

In doing this I found various other things to fix:

* I removed the zonkSimples from TcFlatten.unflattenWanteds; it wasn't
  needed.   But I added one in TcSimplify.floatEqualities, which does
  the zonk precisely when it is needed.

* Trac #13674 showed up a case where we had
     - an insoluble Given,   e.g.  a ~ [a]
     - the same insoluble Wanted   a ~ [a]
  We don't use the Given to rewwrite the Wanted (obviously), but
  we therefore ended up reporting
      Can't deduce (a ~ [a]) from (a ~ [a])
  which is silly.

  Conclusion: when reporting errors, make the occurs check "win"
  See Note [Occurs check wins] in TcErrors

Consider
  type family F a :: * -> *

Then (a ~ F Int a) is an insoluble occurs check, and can be reported
as such.  Previous to this patch, TcType.isInsolubleOccursCheck was
treating any type-family application (including an over-saturated one)
as unconditionally not-insoluble.

This really only affects error messages, and then only slightly. I
tripped over this when investigating  Trac #13674.

Sometimes it's handy to change a compiler flag
for a library in stage{0,1,2}.

Usage example:

    libraries/binary_EXTRA_HC_OPTS += -O1
    libraries/containers_EXTRA_HC_OPTS += -O1
    libraries/bytestring_EXTRA_HC_OPTS += -O1

Here override default -O2 defined in .cabal files
for these libraries to speed build up.

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

This patch fixes two separate bugs which contributed to making
Trac #13752 go wrong

1.  We need to use tcSubType, not tcUnify,
    in tcCheckPatSynDecl.tc_arg.

    Reason: Note [Pattern synonyms and higher rank types]

2.  TcUnify.tc_sub_type had a special case designed to improve error
    messages; see Note [Don't skolemise unnecessarily].  But the
    special case was too liberal, and ended up using unification
    (which led to rejecting the program) when it should instead taken
    the normal path (which accepts the program).

    I fixed this by making the test more conservative.

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

Test Plan: Validate

Reviewers: austin, hvr, dfeuer

Reviewed By: dfeuer

Subscribers: rwbarton, thomie

GHC Trac Issues: #13746

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

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.