GitLab

Previously the Typeable implementation would intentionally create TyCon
representations with bogus fingerprints to avoid fingerprints (which may
change often) from leaking into test output. As pointed out by Richard
in #10376 this is very bad as simply enabling a debug flag,
`-dsuppress-uniques`, completely breaks the soundness of `Typeable`!

This patch removes this behavior and replaces it with logic in the
testsuite driver to filter out spurious changes due to Typeable
representations.

Test Plan: Validate

Reviewers: austin, simonpj, goldfire

Reviewed By: goldfire

Subscribers: thomie

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

GHC Trac Issues: #10376

This was a pretty brutal upgrade, with >100% increase in allocations
while processing `base`. Ugh.

Summary:
(Apologies for the size of this patch, I couldn't make a smaller one
that was validate-clean and also made sense independently)

(Some of this code is derived from GHCJS.)

This commit adds support for running interpreted code (for GHCi and
TemplateHaskell) in a separate process.  The functionality is
experimental, so for now it is off by default and enabled by the flag
-fexternal-interpreter.

Reaosns we want this:

* compiling Template Haskell code with -prof does not require
  building the code without -prof first

* when GHC itself is profiled, it can interpret unprofiled code, and
  the same applies to dynamic linking.  We would no longer need to
  force -dynamic-too with TemplateHaskell, and we can load ordinary
  objects into a dynamically-linked GHCi (and vice versa).

* An unprofiled GHCi can load and run profiled code, which means it
  can use the stack-trace functionality provided by profiling without
  taking the performance hit on the compiler that profiling would
  entail.

Amongst other things; see
https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi for more details.

Notes on the implementation are in Note [Remote GHCi] in the new
module compiler/ghci/GHCi.hs.  It probably needs more documenting,
feel free to suggest things I could elaborate on.

Things that are not currently implemented for -fexternal-interpreter:

* The GHCi debugger
* :set prog, :set args in GHCi
* `recover` in Template Haskell
* Redirecting stdin/stdout for the external process

These are all doable, I just wanted to get to a working validate-clean
patch first.

I also haven't done any benchmarking yet.  I expect there to be slight hit
to link times for byte code and some penalty due to having to
serialize/deserialize TH syntax, but I don't expect it to be a serious
problem.  There's also lots of low-hanging fruit in the byte code
generator/linker that we could exploit to speed things up.

Test Plan:
* validate
* I've run parts of the test suite with
EXTRA_HC_OPTS=-fexternal-interpreter, notably tests/ghci and tests/th.
There are a few failures due to the things not currently implemented
(see above).

Reviewers: simonpj, goldfire, ezyang, austin, alanz, hvr, niteria, bgamari, gibiansky, luite

Subscribers: thomie

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

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

Test Plan: docs only

Reviewers: austin, bgamari

Subscribers: thomie

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

`transformers-0.5.0.0` will be the next version of `transformers`
and this is the designated version to be used for GHC 8.0.1

This needs to update the haskeline submodule in order to relax
the upper bound for the major version bump to 0.5

This needs minor adaptations to ghc-cabal due to
http://git.haskell.org/packages/Cabal.git/commitdiff/b39b906d05c409e4960ae15dbaca89664826a85f

This supercedes the Note recently written in TysWiredIn.

Summary: Fixes #11237

Test Plan: ./validate

Reviewers: goldfire, austin, bgamari

Subscribers: thomie

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

GHC Trac Issues: #11237

Thanks for Matthew Pickering for managing this rebase.

This updates the `unix` submodule to pull in an improved
Autoconf test for `fdatasync(2)` in cases where `<unistd.h>` lacks
a declaration, but linking against `fdatasync` works which led to a
false positive previously.

Also rename and move the horribly named isVanillaLSig to Haddock as
isUserLSig, reflecting the fact that it returns whether the signature
was provided by the user or generated.

This replaces some occurences of `-f(no-)warn` with the new `-W`-aliases
introduced via 2206fa8c / #11218, in cases which are guaranteed
to be invoked with recent enough GHC (i.e. the stage1+ GHC).

After this commit, mostly the compiler and the testsuite remain using
`-f(wo-)warn...` because the compiler needs to be bootstrappable with
older GHCs, while for the testsuite it's convenient to be able to quickly
compare the behavior to older GHCs (which may not support the new flags yet).

The compiler-part can be updated to use the new flags once GHC 8.3 development
starts.

Reviewed By: quchen

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

This also updates the user's guide to refer to the `-W`-based warning
flags by default.

Quoting the release note entry:

| Warnings can now be controlled with `-W(no-)...` flags in addition to
| the old `-f(no-)warn...` ones. This was done as the first part of a
| rewrite of the warning system to provide better control over warnings,
| better warning messages, and more common syntax compared to other
| compilers. The old `-fwarn...`-based warning flags will remain
| functional for the forseeable future.

This is part of
https://ghc.haskell.org/wiki/Design/Warnings
and addresses #11218

Reviewed By: hvr, bgamari

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

This requires tweaking version constraints to allow this new major version
of `binary`.

Starting with binary-0.8, `Binary Version` is de-orphaned into `binary`.
This requires some minor adaptations to remove/hide orphan instances.

/cc @kolmodin

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

The `pretty-1.1.3.2` release is the version designated for GHC 8.0.1

/cc @dterei

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

This exposes `template-haskell` functions for querying the language
extensions which are enabled when compiling a module,

- an `isExtEnabled` function to check whether an extension is enabled
- an `extsEnabled` function to obtain a full list of enabled extensions

To avoid code duplication this adds a `GHC.LanguageExtensions` module to
`ghc-boot` and moves `DynFlags.ExtensionFlag` into it. A happy
consequence of this is that the ungainly `DynFlags` lost around 500
lines. Moreover, flags corresponding to language extensions are now
clearly distinguished from other flags due to the `LangExt.*` prefix.

Updates haddock submodule.

This fixes #10820.

Test Plan: validate

Reviewers: austin, spinda, hvr, goldfire, alanz

Reviewed By: goldfire

Subscribers: mpickering, RyanGlScott, hvr, simonpj, thomie

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

GHC Trac Issues: #10820

There is something very peculiar about the `catch` family of operations
with respect to strictness analysis: they turn divergence into
non-divergence. For this reason, it isn't safe to mark them as strict in
the expression whose exceptions they are catching. The reason is this:

Consider,

    let r = \st -> raiseIO# blah st
    in catch (\st -> ...(r st)..) handler st

If we give the first argument of catch a strict signature, we'll get a
demand 'C(S)' for 'r'; that is, 'r' is definitely called with one
argument, which indeed it is. The trouble comes when we feed 'C(S)' into
'r's RHS as the demand of the body as this will lead us to conclude that
the whole 'let' will diverge; clearly this isn't right.

This is essentially the problem in #10712, which arose when
7c0fff41 marked the `catch*` primops as
being strict in the thing to be evaluated. Here I've partially reverted
this commit, again marking the first argument of these primops as lazy.

Fixes #10712.

Test Plan: Validate checking `exceptionsrun001`

Reviewers: simonpj, austin

Subscribers: thomie

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

GHC Trac Issues: #10712, #11222

Test Plan: Validate

Reviewers: austin, mpickering

Reviewed By: mpickering

Subscribers: mpickering, thomie

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

GHC Trac Issues: #11224

Fixes #11178.

Commit 547c5971 modifies the
pretty-printer to render names from a set of core packages (`base`,
`ghc-prim`, `template-haskell`) as unqualified. The idea here was that
many of these names typically are not in scope but are well-known by the
user and therefore qualification merely introduces noise.

This, however, is a very large hammer and potentially breaks any
consumer who relies on parsing GHC output (hence #11208). This commit
partially reverts this change, now only printing `Constraint` (which
appears quite often in errors) as unqualified.

Fixes #11208.

Updates tests in `array` submodule.

Test Plan: validate

Reviewers: hvr, thomie, austin

Subscribers: thomie

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

GHC Trac Issues: #11208

This patch fulfils the request in Trac #11067, #10318, and #10592,
by lifting the conservative restrictions on superclass constraints.

These restrictions are there (and have been since Haskell was born) to
ensure that the transitive superclasses of a class constraint is a finite
set.  However (a) this restriction is conservative, and can be annoying
when there really is no recursion, and (b) sometimes genuinely recursive
superclasses are useful (see the tickets).

Dimitrios and I worked out that there is actually a relatively simple way
to do the job. It’s described in some detail in

   Note [The superclass story] in TcCanonical
   Note [Expanding superclasses] in TcType

In brief, the idea is to expand superclasses only finitely, but to
iterate (using a loop that already existed) if there are more
superclasses to explore.

Other small things

- I improved grouping of error messages a bit in TcErrors

- I re-centred the haddock.compiler test, which was at 9.8%
  above the norm, and which this patch pushed slightly over

This is really just doucumenting one aspect of the kind-equality patch.

See especially Note [Equality types and classes] in TysWiredIn.
Other places should just point to this Note.

Richard please check for veracity.

In particular, highlight that we do not put bangs on nested patterns

The `process-1.4.1.0` release is the version designated for GHC 8.0.1

/cc @snoyberg

Test Plan: Run tests on a 32 bit platform

Reviewers: austin, hvr, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

This adds documentation of the new `OverloadedLabels` extension to
the users' guide.  Thanks to @bgamari for patiently reminding me
to get this done.  Feedback welcome.

Test Plan: N/A

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: thomie, bgamari

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

Reviewers: austin, bgamari

Reviewed By: austin, bgamari

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

There are currently 2 different ways to test for a static or dynamic
build:

    * Test if WayDyn is in ways
    * Test if Opt_Static is set

The problem is that these can easily go out of sync, especially when
using the
GHC API.

This commit replaces all queries of Opt_Static with an equivalent query
of
WayDyn. This would have prevented bug #8294 and fixes #11154.

Reviewers: hvr, austin, bgamari

Reviewed By: austin, bgamari

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

GHC Trac Issues: #10636

When that variable isn't on (which is always the case on Windows),
`runghc` naively attempts to invoke `ghc` by finding an executable
simply named `ghc`. This won't work if `ghc` doesn't exist (e.g., if
we're building GHC and using `ghc-stage2` instead). A simple fix is to
test for the existence of `ghc` beforehand, and if that fails, fall back
on `ghc-stage2`.

Fixes #11185.

Test Plan: ./validate

Reviewers: austin, hvr, thomie, bgamari

Reviewed By: thomie, bgamari

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

GHC Trac Issues: #11185

Semi-closedness is mentioned in the Haskell report, so lets not hide it
from users.

Reviewers: austin, hvr, bgamari

Reviewed By: bgamari

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

As mentioned in #4426 these warnings are now errors since the Great
Wildcards Refactor of 2015 (1e041b73).
I've opened #11221 to ensure we remove the last traces of the option in
8.2.

Test Plan: validate

Reviewers: austin

Subscribers: thomie

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

GHC Trac Issues: #4426