GitLab

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

This allows to conveniently interpret string literals as `text`
when `-XOverloadedStrings` is in effect.

For what it's worth, `Text.PrettyPrint.Doc` also possesses such
an instance.

This is a spin-off from D1240

Reviewed By: bgamari

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

Previously bindings in `do` blocks were omitted. With `-XStrict`
```lang=hs
do content <- action
   other_things
```
should be equivalent to
```lang=hs
do !content <- action
   other_things
```

Fixes #11193.

Reviewers: bgamari, austin

Reviewed By: bgamari

Subscribers: thomie

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

GHC Trac Issues: #11193

With -XTypeInType, `*` must be imported to be used. This patch makes
sure the user knows this.

But I'm not sure this is the best way to deal with `*`. Feedback welcome
on either this small fix or the approach to `*`, in general.

You may wish to see `Note [HsAppsTy]` in HsTypes if you want to take a
broader view.

Test Plan: dependent/should_fail/RenamingStar

Reviewers: simonpj, bgamari, austin

Subscribers: thomie

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

Summary:
Deriving clauses in the TH representations of data, newtype, data
instance, and newtype instance declarations previously were just [Name],
which didn't allow for more complex derived classes, eg. multi-parameter
typeclasses.

This switches out [Name] for Cxt, representing the derived classes as
types instead of names.

Test Plan: validate

Reviewers: goldfire, spinda, austin

Reviewed By: goldfire, austin

Subscribers: thomie

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

GHC Trac Issues: #10819

This is a follow-up to fcc6b1de / D1608 which is made possible
by the recent Cabal update:

As `ghc-cabal` is called with `--with-gcc`, this gets passed to `./configure`
as `CC=...` argument. So we don't need to set `CC=...` ourselves explicitly again.

Prior to the changes in Cabal (pulled in via  0bf0cf93) and fcc6b1de,
`./configure` scripts would be called with a `--with-cc` argument followed by a
`--with-gcc` argument.

After this commit, `./configure` will be passed a single `CC=...` argument
constructed by the `Cabal` library.

Reviewed By: erikd

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

The non-idiomatic `--with-cc` flag was added via
5c789e42

However, `--with-cc` seems rather fragile and support for `--with-cc` needs
to be added explicitly to autoconf-based Cabal packages. The `CC=` flag, however,
is supported natively by GNU Autoconf, so let's use the standard facility for that.

Relatedly, Cabal prior to version 1.24 used a similiar flag `--with-gcc=...`,
but starting with Cabal-1.24 this has been changed to use `CC=...` instead as well
(see https://github.com/haskell/cabal/pull/2946)

This also updates a few submodules removing the now obsolete `--with-cc` flag
support.

Reviewed By: trofi, thomie, erikd

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

Debian has Renesas SH4 (SuperH) port with a triplet:

    sh4-linux-gnu

Patch by glaubitz adds 'sh4' CPU to recognize target
as ArchUnknown.
Signed-off-by: Sergei Trofimovich <siarheit@google.com>

Fixes #10902.

Test Plan: validate

Reviewers: goldfire, austin, hvr, jstolarek, bgamari

Reviewed By: jstolarek, bgamari

Subscribers: hvr, thomie

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

GHC Trac Issues: #10902

The INSTALL_PROGRAM variable is set in mk/config.mk, so we have to
include that file before using it.

Running 'make install' before './configure' in a bindist will now also
display a nice message.

Reviewers: hvr, austin, bgamari

Reviewed By: bgamari

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

GHC Trac Issues: #1851

Apparently gnu as uses `.short` as a synonym for `.word`. To emit a
16-bit value one would use `.hword`. However, Darwin doesn't support
`.hword`, instead taking `.short` to mean a 16-bit value. The
insanity is nearly unbearable!

OS X reference:
https://developer.apple.com/library/mac/documentation/DeveloperTools/Ref
erence/Assembler/040-Assembler_Directives/asm_directives.html#//apple_re
f/doc/uid/TP30000823-TPXREF101

gnu as reference:
https://sourceware.org/binutils/docs/as/hword.html#hword

Test Plan: Validate

Reviewers: austin

Reviewed By: austin

Subscribers: thomie

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

GHC Trac Issues: #11202

Fixes #11182.

Reviewers: bgamari, simonpj, austin

Reviewed By: simonpj, austin

Subscribers: thomie

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

GHC Trac Issues: #11182