GitLab

I.e. instead of

    .. ghc-flag:: -XUnboxedTuples
        :shortdesc: Enable the use of unboxed tuple syntax.
        :type: dynamic
        :reverse: -XNoUnboxedTuples
        :category:

one simply writes

    .. extension:: UnboxedTuples
        :shortdesc: Enable the use of unboxed tuple syntax.

This allows language extensions to be referenced as

    If :extension:`UnboxedTuples` is enabled, then...

This directive still creates the entries for the `-XUnboxedTuples` flag,
so in particular,

    Set :ghc-flag:`-XUnboxedTuples` if you have to.

still works, and lists of flags in general (e.g. for the manpage)
include these.

I also removed lots of links from the shortdesc of the extensions, when
this link simply points to the section where the extension is defined.

I removed the list of `-X` flags from the flag reference table, but added a
table of extension under “10.1. Language options”

Lots of text in the manual now refers to “extension `Foo`” rather than
“flag `-XFoo`”.

I consider `-XFoo` a historic artifact that stems from when language
extensions were really just flags. These days, the use of `-XFoo` is
(IMHO) deprecated: You should be using `LANGUAGE Foo`, or maybe the
appropriate field in a `.cabal` file. See 9278994a which did this change
to error messages already.

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

This reverts commit 561bdca1.

submodule

This reverts commit f744261a.

Summary: Update to Win32 2.6 which is the expected version release for 8.4

This bumps the required submodule s as well.

Test Plan: ./validate

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie

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

This reverts commit b62097d1.

Summary:
GHC 8.4 is expected to ship with an updated GCC bindist based on GCC 7.2.

I am however at this time not updating the crt due to an issue introduced
in september. https://sourceforge.net/p/mingw-w64/mailman/message/36085637/

Unless a favorable fix comes out of the discussion I will just ship the old crt
with GHC 8.4.

Test Plan: ./validate

Reviewers: austin, bgamari

Subscribers: rwbarton, thomie

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

Summary:
This removes the part of the test that checks whether the timeout happened in
a 'reasonable' amount of time, because it is flaky.
In subsequent work, we can turn this into a benchmark.

Test Plan: This _is_ a test

Reviewers: nh2, bgamari, Phyx, austin, hvr

Reviewed By: Phyx

Subscribers: rwbarton, thomie

GHC Trac Issues: #8684

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

Summary:
Otherwise we can get an iface hash difference, but no indication of what
caused it in the --show-iface output.

Test Plan: Harbourmaster

Reviewers: austin, bgamari, erikd

Subscribers: rwbarton, thomie

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

This fix replaces an utterly bogus error message with a decent one,
rejecting a pattern synonym with a list pattern and rebindable syntax.

Not hard to fix properly, but I'm going to wait for a willing volunteer
and/or more user pressure.

Summary:
This patch adds the ability to generate stack traces on crashes for Windows.
When running in the interpreter this attempts to use symbol information from
the interpreter and information we know about the loaded object files to
resolve addresses to symbols.

When running compiled it doesn't have this information and then defaults
to using symbol information from PDB files. Which for now means only
files compiled with ICC or MSVC will show traces compiled.

But I have a future patch that may address this shortcoming.

Also since I don't know how to walk a pure haskell stack, I can for now
only show the last entry. I'm hoping to figure out how Apply.cmm works to
be able to walk the stalk and give more entries for pure haskell code.

In GHCi

```
$ echo main | inplace/bin/ghc-stage2.exe --interactive ./testsuite/tests/rts/derefnull.hs
GHCi, version 8.3.20170830: http://www.haskell.org/ghc/  :? for help
Ok, 1 module loaded.
Prelude Main>
Access violation in generated code when reading 0x0

 Attempting to reconstruct a stack trace...

   Frame        Code address
 * 0x77cde10    0xc370229 E:\..\base\dist-install\build\HSbase-4.10.0.0.o+0x190031
                 (base_ForeignziStorable_zdfStorableInt4_info+0x3f)
```

and compiled

```
Access violation in generated code when reading 0x0

 Attempting to reconstruct a stack trace...

   Frame        Code address
 * 0xf0dbd0     0x40bb01 E:\..\rts\derefnull.run\derefnull.exe+0xbb01
```

Test Plan: ./validate

Reviewers: austin, hvr, bgamari, erikd, simonmar

Reviewed By: bgamari

Subscribers: rwbarton, thomie

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

This patch clarifies the story for record wildcards,
following the discussion on Trac #14347.

This patch was provoked by Trac #14363.  Turned out that we were
kicking out too many constraints in TcSMonad.kickOutRewritable, and
that mean that the work-list never became empty: infinite loop!

That in turn made me look harder at the Main Theorem in
Note [Extending the inert equalities].

Main changes

* Replace TcType.isTyVarExposed by TcType.isTyVarHead.  The
  over-agressive isTyVarExposed is what caused Trac #14363.
  See Note [K3: completeness of solving] in TcSMonad.

* TcType.Make anyRewriteableTyVar role-aware.  In particular,
      a ~R ty
  cannot rewrite
      b ~R f a
  See Note [anyRewriteableTyVar must be role-aware].  That means
  it has to be given a role argument, which forces a little
  refactoring.

  I think this change is fixing a bug that hasn't yet been reported.
  The actual reported bug is handled by the previous bullet.  But
  this change is definitely the Right Thing

The main changes are in TcSMonad.kick_out_rewritable, and in TcType
(isTyVarExposed ---> isTyVarHead).

I did a little unforced refactoring:

 * Use the cc_eq_rel field of a CTyEqCan when it is available, rather
   than recomputing it.

 * Define eqCanRewrite :: EqRel -> EqRel -> EqRel, and use it, instead
   of duplicating its logic

If the AP_STACK has been evaluated and a GC has run, the BLACKHOLE
indirection will have been removed, and the StablePtr for the original
AP_STACK referred to be GHCi will therefore now point directly to the
value, and may be tagged. Add a hist002 test for this, and make sure
hist001 doesn't do an idle GC, so the case when it's still a BLACKHOLE
is definitely also tested.

Reviewers: austin, bgamari, erikd, simonmar

Reviewed By: simonmar

Subscribers: rwbarton, thomie

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

Test Plan: none

Reviewers: bgamari, austin, hvr

Reviewed By: bgamari

Subscribers: rwbarton, thomie

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

This is the first in a series of regression tests prompted by
https://ghc.haskell.org/trac/ghc/ticket/8684 and D4011, D4012, D4041

Test Plan: This _is_ a test.

Reviewers: nh2, austin, hvr, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie

GHC Trac Issues: #8684

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

This diff exposes the monotonic time api from GHC.Event.Clock.

This is necessary for future work on regression tests (#D4074) for
the timeout problems (8684, for example) in #D4041, #D4011, #D4012

Test Plan: Still builds ...

Reviewers: nh2, bgamari, austin, hvr

Reviewed By: bgamari

Subscribers: rwbarton, thomie

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

so now “7.6.12. Language options” only lists `-X` flags, as it should.

Summary:
I ended up needing to use the functionality of
`injectiveVarsOfBinder`/`injectiveVarsOfType` in this Haddock PR
(https://github.com/haskell/haddock/pull/681), but alas, neither of
these functions were exported. Let's do so.

Test Plan: Does it compile?

Reviewers: austin, goldfire, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie

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

Summary:
Previously, GHC would always raise the possibility that a
type family might not be injective in certain error messages, even if
that type family actually //was// injective. Fix this by actually
checking for a type family's lack of injectivity before emitting
such an error message.

Test Plan: ./validate

Reviewers: goldfire, austin, bgamari, simonpj

Reviewed By: simonpj

Subscribers: simonpj, rwbarton, thomie

GHC Trac Issues: #14369

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

Summary:
According to the GHC users' guide, one cannot derive
instances for data types in `.hs-boot` files.
However, GHC was not enforcing this in practice, which led to
#14365.

Fix this by actually throwing an error if a derived instance is
detected in an `.hs-boot` file (and recommend how to fix it in the
error message.)

Test Plan: make test TEST=T14365

Reviewers: ezyang, austin, bgamari, simonpj

Reviewed By: simonpj

Subscribers: simonpj, rwbarton, thomie

GHC Trac Issues: #14365

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

Summary:
It's well known that `-XRebindableSyntax` doesn't play
nicely with some of the internal expressions that GHCi runs. #13385
was one example where this problem arose, which was fixed at the time
by simply avoiding the use of `do`-notation in these internal GHCi
expressions. That seemed to work, but it was a technique that proved
not to scale, as #14342 demonstrated //another// example where
`-XRebindableSyntax` can bite.

Instead of delicately arranging the internal GHCi expressions to
avoid anything that might be covered under `-XRebindableSyntax`,
this patch takes the much more direct approach of disabling
`-XRebindableSyntax` entirely when running any internal GHCi
expression. This shouldn't hurt, since nothing internal to GHCi was
taking advantage of the extension in the first place, and moreover,
we can have greater confidence that some other obscure
`-XRebindableSyntax` corner case won't pop up in the future. As an
added bonus, this lets us once again use `do`-notation in the code
that had to be changed when #13385 was (hackily) fixed before.

Test Plan: make test TEST=T14342

Reviewers: bgamari, austin

Subscribers: rwbarton, thomie

GHC Trac Issues: #14342

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

This patch adds a bit of extra solving power for representational
equality constraints to fix Trac #14333

The main changes:

* Fix a buglet in TcType.isInsolubleOccursCheck which wrongly
  reported a definite occurs-check error for (a ~R# b a)

* Get rid of TcSMonad.emitInsolubles.  It had an ad-hoc duplicate-removal
  piece that is better handled in interactIrred, now that insolubles
  are Irreds.

  We need a little care to keep inert_count (which does not include
  insolubles) accurate.

* Refactor TcInteract.solveOneFromTheOther, to return a much simpler
  type.  It was just over-complicated before.

* Make TcInteract.interactIrred look for constraints that match
  either way around, in TcInteract.findMatchingIrreds

This wasn't hard and it cleaned up quite a bit of code.

Trac #13450 went bananas if we expand insoluble constraints.
Better just to leave them un-expanded.

I'm not sure in detail about why it goes so badly wrong; but
regardless, the less we mess around with insoluble contraints
the better the error messages will be.

In particular:
 * add an intro to “10.6. Extensions to the “deriving” mechanism” giving
   an overview,
 * make the various sections on `-XDerivingFoo` subsections of
   “10.6.3. Deriving instances of extra classes (Data, etc.)”
 * Move the reference anchors for the various `DerivingFoo` extensions
   to a more appropriate spot.
 * Add subsection “10.6.6.1. Default deriving strategy” to the
   deriving section (#14357)