A GADT declaration surrounded in parens does not det the con_forall
field correctly.

e.g.

data MaybeDefault v where
    TestParens  :: (forall v . (Eq v) => MaybeDefault v)

Closes #15323

It shouldn't be necessary to lock the `MVar` closure on `tryReadMVar`, since it
just reads one field of the structure and doesn't make any modifications. So
let's not.

Reviewers: bgamari, erikd, simonmar, fryguybob, osa1

Reviewed By: osa1

Subscribers: osa1, rwbarton, thomie, carter

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

Reviewers: bgamari

Subscribers: rwbarton, thomie, carter

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

Reviewers: simonmar, bgamari, erikd

Reviewed By: simonmar

Subscribers: rwbarton, thomie, carter

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

Comments only: [ci skip]

Remove unsafeCoerce introduced by a54c94f0

Reviewers: simonmar, bgamari

Reviewed By: simonmar

Subscribers: rwbarton, thomie, carter

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

Reviewers: simonmar, bgamari

Subscribers: rwbarton, thomie, carter

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

...provoked by Trac #15308

The level numbers we were getting simply didn't obey the
invariant (ImplicInv) in TcType
   Note [TcLevel and untouchable type variables]

That leads to chaos. Easy to fix.  I improved the documentation.

I also added an assertion in TcSimplify that checks that
level numbers go up by 1 as we dive inside implications, so
that we catch the problem at source rather than than through
its obscure consequences.

That in turn showed up that TcRules was also generating
constraints that didn't obey (ImplicInv), so I fixed that too.
I have no idea what consequences were lurking behing that
bug, but anyway now it's fixed.  Hooray.

Make sure the original annotations are still accessible for a promoted
type.

Closes #15303

I wondered if some transformations (ticks) might be "innocuous",
in the sense that they do not unlock a later transformation that
does not occur in the same pass.  If so, we could refrain from
bumping the overall tick-count for such innocuous transformations,
and perhaps terminate the simplifier one pass earlier.

BUt alas I found that virtually nothing was innocuous!  This
commit just adds a Note to record what I learned, in case
anyone wants to try again.

... plus, reorder equations in toIfaceVar to improve
legibility.  No change in behaviour.

See Trac #15205

The refactoring here is driven by the ghastly mess described in
comment:24 of Trac #1520.  The overall goal is to simplify the
kind-checking of typev-variable binders, and in particular to narrow
the use of the "in-scope tyvar binder" stuff,
which is needed only for associated types: see the new
Note [Kind-checking tyvar binders for associated types] in TcHsType.

Now

* The "in-scope tyvar binder" stuff is done only in
     - kcLHsQTyVars, which is used for the LHsQTyVars of a
       data/newtype, or type family declaration.

     - tcFamTyPats, which is used for associated family instances;
       it now calls tcImplicitQTKBndrs, which in turn usese
       newFlexiKindedQTyVar

* tcExpicitTKBndrs (which is used only for function signatures,
  data con signatures, pattern synonym signatures, and expression
  type signatures) now does not go via the "in-scope tyvar binder"
  stuff at all.

While I'm still not happy with all this code, the code is generally
simpler, and I think this is a useful step forward. It does cure
the problem too.

(It's hard to trigger the problem in vanilla Haskell code, because
the renamer would normally use different names for nested binders,
so I can't offer a test.)

As Trac #15289 showed, we were carrying on after a type error
in a pattern synonym, and then crashing.  This patch improves
error handling for pattern synonyms.

I also moved a bit of code from TcBinds into TcPatSyn, which
helpfully narrows the API.

Test Plan: "ghc -Wamp XXX.hs"  should give "unrecognised warning flag"

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #11477

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

protect mmaped addresses from writes after being initially manipulated

Test Plan: ./validate

Reviewers: bgamari, erikd, simonmar

Reviewed By: bgamari

Subscribers: angerman, carlostome, rwbarton, thomie, carter

GHC Trac Issues: #14069

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

Ben Gamari authored 6 years ago and Ben Gamari committed 6 years ago

Currently we belch some output to stderr but fail to abort, resulting in
a busy loop. Fixes #15292.

Test Plan:
 * Validate
 * try running program under environment without timerfd capabilities;
ensure we don't busy-loop

Reviewers: simonmar, erikd

Reviewed By: simonmar

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #15929

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

Previously, the `make clean` (as well as `make dist-clean`) doesn't work
for ghc-heap and libiserv, due to these two libraries are not presented
in the "packages" file.

Test Plan: [skip ci]

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

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

We just update the docs to reflect the state of affairs.

opt-cmm is run by the NCG backend so not always run.
ddump-cmm-verbose only dumps passes of the cmm
pipeline so it's not included there. [skip-ci]

Test Plan: doc change

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

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

The standard[1] for extension naming is to use the XC prefix for the
internal extension points, rather than for a new constructor.

This is violated for IPBind, having

    data IPBind id
      = IPBind
            (XIPBind id)
            (Either (Located HsIPName) (IdP id))
            (LHsExpr id)
      | XCIPBind (XXIPBind id)

Swap the usage of XIPBind and XCIPBind

[1] https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow#Namingconventions

Closes #15302

We call checkReductionDepth in chooseInstance, so there's no
need to call it in selectNextWorkItem too

This patch just removes the CtLoc parameter from trySolveFromInstance,
since it can just as easily (and more uniformly) be gotten from the
CtEvidence it is trying to solve.

Trac #15290 showed that it's possible that we might attempt to use a
quantified constraint to solve an equality in a situation where we
don't have anywhere to put the evidence bindings.  This made GHC crash.

This patch stops the crash, but still rejects the pogram.  See
Note [Instances in no-evidence implications] in TcInteract.

Finding this bug revealed another lurking bug:

* An infelicity in the treatment of superclasses -- we were expanding
  them locally at the leaves, rather than at their binding site; see
  (3a) in Note [The superclass story].

  As a consequence, TcRnTypes.superclassesMightHelp must look inside
  implications.

In more detail:

* Stop the crash, by making TcInteract.chooseInstance test for
  the no-evidence-bindings case.  In that case we simply don't
  use the instance.  This entailed a slight change to the type
  of chooseInstance.

* Make TcSMonad.getPendingScDicts (now renamed getPendingGivenScs)
  return only Givens from the /current level/; and make
  TcRnTypes.superClassesMightHelp look inside implications.

* Refactor the simpl_loop and superclass-expansion stuff in
  TcSimplify.  The logic is much easier to understand now, and
  has less duplication.

Richard added a much better version of this Note in commit
26e9806a, so I've decided to point
to that instead.

This is an unstable release, hence it must be x.y.$DATE, rather than x.y.0.$DATE
which would denote a stable pre-release snapshot.

Bumps haddock submodule.

Bumps containers submodule, among others.

Moritz Angermann authored 6 years ago and Ben Gamari committed 6 years ago

When GHC links binaries on windows, we pass a -L and -l flag
to gcc for each dependency in the transitive dependency
closure.  As this will usually overflow the command argument
limit on windows, we use response files to pass all arguments
to gcc.  gcc however internally passes only the -l flags via
a response file to the collect2 command, but puts the -L flags
on the command line. As such if we pass enough -L flags to
gcc--even via a response file--we will eventually overflow the
command line argument length limit due to gcc passing them
to collect2 without resorting to a response file.

To prevent this from happening we move all lirbaries into a
shared temporary folder, and only need to pass a single -L
flag to gcc.  Ideally however this was fixed in gcc.

Reviewers: bgamari, Phyx

Reviewed By: bgamari

Subscribers: erikd, rwbarton, thomie, carter

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