GitLab

Under --slow, the DPH tests can take incredible amounts of time to run.
And on some platforms, we may not have a fully working linker in order
to build DPH etc anyway. So this provides a way to turn it off.

This flag is off by default, but should your specify it, you can skip
the required 'dph' libraries in a build, should you remove them from the
source tree.
Signed-off-by: Austin Seipp <aseipp@pobox.com>

Parser.hs needs to be compiled with -fcmm-sink on x86 platforms, so the
register allocator doesn't run out of stack slots. Previously, we had to
do some CPP hacks in order to emit an #ifdef into the file - this is
because we preprocess it once up front, and run the preprocessor again
when we compile it.

There's two cases: the boostrap compiler is > 7.8, and the stage1 parser
needs the flag, or the stage1 compiler is compiling the stage2
Parser.hs, and needs the flag..

The previous approach was super fragile with Clang. The more principled
fix is to instead do this through the build system.

This fixes #8182.
Signed-off-by: Austin Seipp <aseipp@pobox.com>

It's been deprecated for who knows how long, and gives a warning.
Signed-off-by: Austin Seipp <aseipp@pobox.com>

Signed-off-by: Austin Seipp <aseipp@pobox.com>

And update comments

When inferring roles it is Much More Kosher to work on the source
type, as written by the user, rather than the representation type as
computed by GHC.  Error messages may be better and, more subtly, the
representation type is the result of a pretty complicated calculation
and I'm worried about accidental cycles.

Now that IfBangs can contain coercions, which can mention the
very type being typechecked, the tc_strict call must be inside
forkM. This led to Trac #8221

This bug meant that we tried to unpack Link in

  data Link a = MkLink !(Link a)

when -funbox-small-strict-fields was on.  See Trac #8221.

We have various problems with reallocating the array of Capabilities,
due to threads in waitForReturnCapability that are already holding a
pointer to a Capability.

Rather than add more locking to make this safer, I decided it would be
easier to ensure that we never move the Capabilities at all.  The
capabilities array is now an array of pointers to Capabaility.  There
are extra indirections, but it rarely matters - we don't often access
Capabilities via the array, normally we already have a pointer to
one.  I ran the parallel benchmarks and didn't see any difference.

For some reason, the new `GccIsClang` variable introduced via
fc4856f9 for addressing #8148
isn't set explicitly to `NO`; so this simply changes the test
`ifeq $(GccIsClang) NO` to `ifneq $(GccIsClang) YES` which
should fix the build with and w/o Clang.

* This partially fixes #8148. However, --with-ghc-4.8 will still not work given the rather dubious m4 macros and the failures in the test suite due to '-nodefaultlibs' still need to be fixed.

The original problem was that we weren't bringing varaibles bound in the
interactive context into scope before Linting the result of a top-level
declaration in GHCi.  (We were doing this for expressions.)

Moreover I found that we weren't Linting the result of desugaring
a GHCi expression, which we really should be doing.

It took me a bit of time to unravel all this, and I did some refactoring
to make it easier next time.

  * CoreMonad contains the Lint wrappers that get the right
    environments into place.  It always had endPass and lintPassResult
    (which Lints bindings), but now it has lintInteractiveExpr.

  * Both use a common function CoreMonad.interactiveInScope to find
    those in-scope variables.

Quite a bit of knock-on effects from this, but nothing exciting.

Fixing #8217 for the unix(-like) case.

By keeping the repository url in the `packages` file scripts such as
source:ghc/sync-all can pick it up. Moreover, it's easier to
automatically validate for correctness than the
wiki:Repositories/Upstream page.

* Document ExplicitNamespaces
* Improve documentation of ambiguity, and AllowAmbiguousTypes
* Improve documentation of overlapping/incoherent instance rules
* List language extensions in alphabetical order

This is a lingering bug from the introduction of polymorphic kinds.
In the specialiser we were specialising over a type, but failing
to specialise over the kinds it mentions.

The fix is simple: add a call to closeOverKinds.

Most of the patch is to add closeOverKinds, and to use it in a few
other places where we are doing essentially the same thing.

Part of Nick Frisby's patch (c080f727)
for late demand-analysis removed the over-zealous short-cut whereby
strictness wrappers were not spelled out in detail in interface files.

This patch completes the process by
 * removing InlineWrapper from UnfoldingSource
 * removing IfWrapper from IfaceUnfolding

There was a tiny bit of special ad-hocery for wrappers, in OccurAnal,
but fortunately that too turns out to be rendered irrelevant by
the more uniform treatment, and after that there was no need
to remember which functions are wrappers.

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

This basically turns the comment at the beginning of the `validate`
shell script into an interactive `--help` output plus some minor additions.

(+ 3 outstanding local patches)

Signed-off-by: Austin Seipp <aseipp@pobox.com>

Signed-off-by: Austin Seipp <aseipp@pobox.com>

The function was reading past the end of the FastString table, causing
the -dfaststring-stats option to behave unpredictably.

Fixes #8200