GitLab

Updates haddock submodule to match.

Test Plan : Validate

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

Summary:
Before, GHC would never print visible tyvars in the absence
of `-fprint-explicit-foralls`, which led to `:kind` displaying
incorrect kinds in GHCi. The fix is simple—simply check beforehand
if any of the type variable binders are required when deciding when
to pretty-print them.

Test Plan: make test TEST=T14238

Reviewers: simonpj, goldfire, bgamari

Subscribers: thomie, carter

GHC Trac Issues: #14238

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

Summary: This seems to have changed recently but the new output looks plausible.

Reviewers: RyanGlScott

Reviewed By: RyanGlScott

Subscribers: RyanGlScott, thomie, carter

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

Summary:
The typechecker started trying to pull in GHC.Integer.Type's interface file
due to the change made in d8d4266b. It's unclear
why the patch in question changed this behavior, but these typechecker-induced
dependencies are known to be a bit fragile and adding these imports ensures
that the build order is correct.

Test Plan: Validate

Reviewers: goldfire, hvr

Subscribers: thomie, carter

GHC Trac Issues: #15004

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

Reviewers: bgamari, simonmar, erikd

Reviewed By: bgamari, simonmar

Subscribers: thomie, carter

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

I introduced a silly bug in

  commit 9187d5fb
  Date:   Mon Apr 2 14:55:43 2018 +0100

  Allow unpacking of single-data-con GADTs

that made test T7050 diverge.  This patch fixes it.

It turns out that solveEqualities really does need to use simpl_top.
I thought that solveWanteds would be enough, and no existing test
case showed up the different. #14991 shows that we need simpl_top.
Easy enough to fix.

test case: dependent/should_compile/T14991

This fixes the SplitWD "unexpected pass". This test was fixed
by ef443820 and somehow fell
through my validation cracks.

This commit:

  commit fb050a33
  Author: Simon Peyton Jones <simonpj@microsoft.com>
  Date:   Thu Oct 12 11:00:19 2017 +0100

  Do not bind coercion variables in SpecConstr rules

arranged to reject any SpecConstr call pattern that mentioned
a coercion in the pattern.

There was a good reason for that
-- see Note [SpecConstr and casts] --
but I didn't realise how important it was to accept patterns
that mention casts in /terms/.  Trac #14936 showed this up.

This patch just narrows the restriction to discard only
the cases where the coercion is mentioned only in types.
Fortunately that was pretty easy to do.

Trac #14978 pointed out that single-constructor GADTs should be
unpackable without trouble.

Acutally I realise that even existentials should be unpackable
too, but that's a bit more work, so it's not part of this patch.

See Note [Unpacking GADTs and existentials] in MkId.

These were fixed by faec8d35

test cases: typecheck/should_fail/T14884
            ghci/scripts/T14969

[skip ci]

Matching in the presence of casts can happen in liftCoMatch, too.

The main job of this commit is to track more accurately the scope
of tyvars introduced by user-written foralls. For example, it would
be to have something like this:

  forall a. Int -> (forall k (b :: k). Proxy '[a, b]) -> Bool

In that type, a's kind must be k, but k isn't in scope. We had a
terrible way of doing this before (not worth repeating or describing
here, but see the old tcImplicitTKBndrs and friends), but now
we have a principled approach: make an Implication when kind-checking
a forall. Doing so then hooks into the existing machinery for
preventing skolem-escape, performing floating, etc. This also means
that we bump the TcLevel whenever going into a forall.

The new behavior is done in TcHsType.scopeTyVars, but see also
TcHsType.tc{Im,Ex}plicitTKBndrs, which have undergone significant
rewriting. There are several Notes near there to guide you. Of
particular interest there is that Implication constraints can now
have skolems that are out of order; this situation is reported in
TcErrors.

A major consequence of this is a slightly tweaked process for type-
checking type declarations. The new Note [Use SigTvs in kind-checking
pass] in TcTyClsDecls lays it out.

The error message for dependent/should_fail/TypeSkolEscape has become
noticeably worse. However, this is because the code in TcErrors goes to
some length to preserve pre-8.0 error messages for kind errors. It's time
to rip off that plaster and get rid of much of the kind-error-specific
error messages. I tried this, and doing so led to a lovely error message
for TypeSkolEscape. So: I'm accepting the error message quality regression
for now, but will open up a new ticket to fix it, along with a larger
error-message improvement I've been pondering. This applies also to
dependent/should_fail/{BadTelescope2,T14066,T14066e}, polykinds/T11142.

Other minor changes:
 - isUnliftedTypeKind didn't look for tuples and sums. It does now.

 - check_type used check_arg_type on both sides of an AppTy. But the left
   side of an AppTy isn't an arg, and this was causing a bad error message.
   I've changed it to use check_type on the left-hand side.

 - Some refactoring around when we print (TYPE blah) in error messages.
   The changes decrease the times when we do so, to good effect.
   Of course, this is still all controlled by
   -fprint-explicit-runtime-reps

Fixes #14066 #14749

Test cases: dependent/should_compile/{T14066a,T14749},
            dependent/should_fail/T14066{,c,d,e,f,g,h}

Summary:
Sometimes we need to be able to mass accept changes that are platform
specific and that can't be normalized away using our string formatters.

e.g. differences in I/O manager errors or behaviors. This allows one
to do so easier than before and less error prone.

I have updated the docs and made it clear this should only be used
when a normalizer won't work:

https://ghc.haskell.org/trac/ghc/wiki/Building/RunningTests/Updating

Test Plan: Manually tested while working on new I/O manager

Reviewers: bgamari

Subscribers: thomie, carter

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

Summary:
This shims out fopen and sopen so that they use modern APIs under the hood
along with namespaced paths.

This lifts the MAX_PATH restrictions from Haskell programs and makes the new
limit ~32k.

There are only some slight caveats that have been documented.

Some utilities have not been upgraded such as lndir, since all these things are
different cabal packages I have been forced to copy the source in different places
which is less than ideal. But it's the only way to keep sdist working.

Test Plan: ./validate

Reviewers: hvr, bgamari, erikd, simonmar

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #10822

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

Reviewers: bgamari, erikd, simonmar

Reviewed By: bgamari

Subscribers: thomie, carter

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

[skip ci]

Now we use the images from the ‘ghcci’ account on docker hub.

The sinking pass often gets rid of unnecessary registers
registers/assignements exposing more opportunities for CBE, so this
commit adds a second round of CBE after the sinking pass and should
fix #12915 (and some examples in #14226).

Nofib results:
* Binary size:         0.9% reduction on average
* Compile allocations: 0.7% increase on average
* Runtime:             noisy, two separate runs of nofib showed a tiny
                       reduction on average, (~0.2-0.3%), but I think
                       this is mostly noise
* Compile time:        very noisy, but generally within +/- 0.5% (one
                       run faster, one slower)

One interesting part of this change is that running CBE invalidates
results of proc-point analysis. But instead of re-doing the whole
analysis, we can use the map that CBE creates for replacing/comparing
block labels (maps a redundant label to a useful one) to update the
results of proc-point analysis. This lowers the overhead compared to the
previous experiment in #12915.
Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com>

Test Plan: ./validate

Reviewers: bgamari, simonmar

Reviewed By: simonmar

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #12915, #14226

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

Test Plan: Try running configure on Windows with msys and mingw
toolchains

Reviewers: Phyx, hvr

Reviewed By: Phyx

Subscribers: rwbarton, thomie, erikd, carter

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

Only half of the test files were checked in for T13938.
This commit adds the missing half.

Trac #13900 showed that when we have a join point that
has a RULE, we must push the continuation into the RHS
of the RULE.

See Note [Rules and unfolding for join points]

It's hard to tickle this bug, so I have not added a regression test.

Minor refactor and comments, following Ryan's excellent DeriveAnyClass
bug (Trac #14932)

I took 10 minute to fix this potential performance hole
(Trac #14263)

There are no actual bug reports against it, so no regression
test.

This patch, authored by alexvieth and reviewed at D4451,
makes performance improvements by critically optimizing parts
of the flattener.

Summary:
T3064, T5321FD, T5321Fun, T9872a, T9872b, T9872c all pass.
T9872a and T9872c show improvements beyond the -5% threshold.
T9872d fails at 10.9% increased allocations.

This changes a key invariant of the flattener. Previously,
flattening a type meant flattening its kind as well. But now,
flattening is always homogeneous -- that is, the kind of the
flattened type is the same as the kind of the input type.
This is achieved by various wizardry in the TcFlatten.flatten_many
function, as described in Note [flatten_many].

There are several knock-on effects, including some refactoring
in the canonicalizer to take proper advantage of the flattener's
changed behavior. In particular, the tyvar case of can_eq_nc' no
longer needs to take casts into account.

Another effect is that flattening a tyconapp might change it
into a casted tyconapp. This might happen if the result kind
of the tycon contains a variable, and that variable changes
during flattening. Because the flattener is homogeneous, it tacks
on a cast to keep the tyconapp kind the same. However, this
is problematic when flattening CFunEqCans, which need to have
an uncasted tyconapp on the LHS and must remain homogeneous.
The solution is a more involved canCFunEqCan, described in
Note [canCFunEqCan].

This patch fixes #13643 (as tested in typecheck/should_compile/T13643)
and the panic in typecheck/should_compile/T13822 (as reported in #14024).
Actually, there were two bugs in T13822: the first was just some
incorrect logic in tryFill (part of the unflattener) -- also fixed
in this patch -- and the other was the main bug fixed in this ticket.

The changes in this patch exposed a long-standing flaw in OptCoercion,
in that breaking apart an AppCo sometimes has unexpected effects on
kinds. See new Note [EtaAppCo] in OptCoercion, which explains the
problem and fix.

Also here is a reversion of the major change in
09bf135a, affecting ctEvCoercion.
It turns out that making the flattener homogeneous changes the
invariants on the algorithm, making the change in that patch
no longer necessary.

This patch also fixes:
  #14038 (dependent/should_compile/T14038)
  #13910 (dependent/should_compile/T13910)
  #13938 (dependent/should_compile/T13938)
  #14441 (typecheck/should_compile/T14441)
  #14556 (dependent/should_compile/T14556)
  #14720 (dependent/should_compile/T14720)
  #14749 (typecheck/should_compile/T14749)

Sadly, this patch negatively affects performance of type-family-
heavy code. The following patch fixes these performance degradations.
However, the performance fixes are somewhat invasive and so I've
kept them as a separate patch, labeling this one as [skip ci] so
that validation doesn't fail on the performance cases.

Commit 94f02547
added some pragmas that allow GCC to compile GHC, but stop
macOS's clang. This adds another counter-pragma to halp
clang lumber along, too.

Fixes #14977.

StgLam can't have empty arguments. Reflect this in types. An assertion
can now be deleted.

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

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