GitLab

Summary:
GHC 8.4 corresponds to 804, not 840.

Found by Gabor Greif.

Test Plan: Harbormaster

Reviewers: ggreif, bgamari, mpickering

Reviewed By: ggreif

Subscribers: rwbarton, carter

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

Long ago, the stable name table and stable pointer tables were one.
Now, they are separate, and have significantly different
implementations. I believe the time has come to finish the split
that began in #7674.

* Divide `rts/Stable` into `rts/StableName` and `rts/StablePtr`.

* Give each table its own mutex.

* Add FFI functions `hs_lock_stable_ptr_table` and
`hs_unlock_stable_ptr_table` and document them.
  These are intended to replace the previously undocumented
`hs_lock_stable_tables` and `hs_lock_stable_tables`,
  which are now documented as deprecated synonyms.

* Make `eqStableName#` use pointer equality instead of unnecessarily
comparing stable name table indices.

Reviewers: simonmar, bgamari, erikd

Reviewed By: bgamari

Subscribers: rwbarton, carter

GHC Trac Issues: #15555

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

Summary:
One of the constant folding rules introduced in D2858 is:

```
(L y :-:   v) :-: (L x :-: w) -> return $ mkL (y-x)   `add` (w `add` v)
```

Or, after removing syntactic noise: `(y - v) - (x - w) ==> (y - x) + (w + v)`.
This is incorrect, since the sign of `v` is changed from negative to positive.
As a consequence, the following program prints `3` when compiled with `-O`:

```
-- This is just subtraction in disguise
minus :: Int -> Int -> Int
minus x y = (8 - y) - (8 - x)
{-# NOINLINE minus #-}

main :: IO ()
main = print (2 `minus` 1)
```

The correct rule is: `(y - v) - (x - w) ==> (y - x) + (w - v)`.

This commit does the fix. I haven't found any other issues with the constant
folding code, but it's difficult to be certain without some automated checking.

Reviewers: bgamari, tdammers

Subscribers: hsyl20, tdammers, rwbarton, carter

GHC Trac Issues: #15569

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

Summary:
When renaming kind variables in an `LHsQTyVars`, we were
erroneously putting all of the kind variables in the binders
//after// the kind variables in the body, resulting in #15568. The
fix is simple: just swap the order of these two around.

Test Plan: make test TEST=T15568

Reviewers: simonpj, bgamari, goldfire

Reviewed By: goldfire

Subscribers: goldfire, rwbarton, carter

GHC Trac Issues: #15568

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

Summary:
When converting `ConT`s to `HsTyVar`s in `Convert`, we were
failing to account for the possibility of promoted data constructor
names appearing in a `ConT`, which could result in improper
pretty-printing results (as observed in #15572). The fix is
straightforward: use `Promoted` instead of `NotPromoted` when the
name of a `ConT` is a data constructor name.

Test Plan: make test TEST=T15572

Reviewers: goldfire, bgamari, simonpj, monoidal

Reviewed By: goldfire, simonpj

Subscribers: monoidal, rwbarton, carter

GHC Trac Issues: #15572

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

Summary:
PrefixPred and AnySuffixPred are not used
since static flags were removed in bbd3c399.

Test Plan: validate

Reviewers: bgamari, tdammers

Reviewed By: tdammers

Subscribers: rwbarton, carter

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

Summary: These can be treated similarly to MUT_ARRY_PTRS. Fixes #15529.

Reviewers: erikd, simonmar

Reviewed By: simonmar

Subscribers: RyanGlScott, rwbarton, carter

GHC Trac Issues: #15529

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

Summary:
These packages were removed from the GHC source tree in
Phab:D4761 and 0905fec0.

Reviewers: RyanGlScott, bgamari

Reviewed By: RyanGlScott

Subscribers: rwbarton, carter

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

Summary:
Previously, we were using foldl1 instead, which led to the derived
code to be wrongly associated.

Test Plan: ./validate

Reviewers: RyanGlScott, nomeata, simonpj, bgamari

Reviewed By: RyanGlScott, nomeata

Subscribers: rwbarton, carter

GHC Trac Issues: #10859

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

Summary:
Currently, reifying classes produces class methods with
redundant tyvars and class contexts in their type signatures, such
as in the following:

```lang=haskell
class C a where
  method :: forall a. C a => a
```

Fixing this is very straightforward: just apply `tcSplitMethodTy` to
the type of each class method to lop off the redundant parts.

It's possible that this could break some TH code in the wild that
assumes the existence of these tyvars and class contexts, so I'll
advertise this change in the release notes just to be safe.

Test Plan: make test TEST="TH_reifyDecl1 T9064 T10891 T14888"

Reviewers: goldfire, bgamari, simonpj

Reviewed By: simonpj

Subscribers: simonpj, rwbarton, carter

GHC Trac Issues: #15551

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

Summary:
The current pattern-match coverage checker implements the
formalism presented in the //GADTs Meet Their Match// paper in a
fairly faithful matter. However, it was discovered recently that
there is a class of unreachable patterns that
//GADTs Meet Their Match// does not handle: unreachable code due to
strict argument types, as demonstrated in #15305. This patch
therefore goes off-script a little and implements an extension to
the formalism presented in the paper to handle this case.

Essentially, when determining if each constructor can be matched on,
GHC checks if its associated term and type constraints are
satisfiable. This patch introduces a new form of constraint,
`NonVoid(ty)`, and checks if each constructor's strict argument types
satisfy `NonVoid`. If any of them do not, then that constructor is
deemed uninhabitable, and thus cannot be matched on. For the full
story of how this works, see
`Note [Extensions to GADTs Meet Their Match]`.

Along the way, I did a little bit of much-needed refactoring. In
particular, several functions in `Check` were passing a triple of
`(ValAbs, ComplexEq, Bag EvVar)` around to represent a constructor
and its constraints. Now that we're adding yet another form of
constraint to the mix, I thought it appropriate to turn this into
a proper data type, which I call `InhabitationCandidate`.

Test Plan: make test TEST=T15305

Reviewers: simonpj, bgamari

Reviewed By: simonpj

Subscribers: rwbarton, carter

GHC Trac Issues: #15305

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

Summary:
When turning an `IntegerL` to an `IntegralLit` during TH
conversion, we were stupidly casting an `Integer` to an `Int` in
order to determine how it should be pretty-printed. Unsurprisingly,
this causes problems when the `Integer` doesn't lie within the bounds
of an `Int`, as demonstrated in #15502.

The fix is simple: don't cast to an `Int`.

Test Plan: make test TEST=T15502

Reviewers: bgamari, simonpj

Reviewed By: simonpj

Subscribers: simonpj, rwbarton, carter

GHC Trac Issues: #15502

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

Summary:
When converting a `RuleP` to a GHC source `RuleD` during TH
conversion, we were stupidly not double-quoting the name of the rule.
Easily fixed.

Test Plan: make test TEST=T15550

Reviewers: goldfire, bgamari, simonpj

Reviewed By: simonpj

Subscribers: simonpj, rwbarton, carter

GHC Trac Issues: #15550

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

Summary:
This completes the work started in D4227 by using just 'getExecutablePath'
in ghc and ghc-pkg when building with base >= 4.11.0.

On the long term, we will be able to simply kill the existing code that
follows (or not) symlinks and just get this behaviour for free from
getExecutable. For now we however have to require base >= 4.11.0 to be able
to just use getExecutablePath under Windows, and use the current code when
building with an older base.

Original code by @alpmestan commandeering since patch has been stale
and bug remains open.

Test Plan: Validate

Reviewers: angerman, bgamari, erikd, alpmestan

Reviewed By: bgamari

Subscribers: carter, rwbarton, thomie

GHC Trac Issues: #14483

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

This patch fixes Trac #15558.  There turned out to be
two distinct problems

* In TcExpr.tc_poly_expr_nc we had

    tc_poly_expr_nc (L loc expr) res_ty
      = do { traceTc "tcPolyExprNC" (ppr res_ty)
           ; (wrap, expr')
               <- tcSkolemiseET GenSigCtxt res_ty $ \ res_ty ->
                  setSrcSpan loc $
                    -- NB: setSrcSpan *after* skolemising,
                    -- so we get better skolem locations
                  tcExpr expr res_ty

  Putting the setSrcSpan inside the tcSkolemise means that
  the location on the Implication constraint is the /call/
  to the function rather than the /argument/ to the call,
  and that is really quite wrong.

  I don't know what Richard's comment NB means -- I moved the
  setSrcSpan outside, and the "binding site" info in error
  messages actually improved.

  The reason I found this is that it affects the span reported
  for Trac #15558.

* In TcErrors.mkGivenErrorReporter we carefully munge the location
  for an insoluble Given constraint (Note [Inaccessible code]).
  But the 'implic' passed in wasn't necesarily the immediately-
  enclosing implication -- but for location-munging purposes
  it jolly well should be.

  Solution: use the innermost implication. This actually
  simplifies the code -- no need to pass an implication in to
  mkGivenErrorReporter.

Provoked by discussion on Phab:D5097 (Trac #15546), I'm adding
a big Note explaing the strategy of pretty-printing via IfaceSyn

Triggered by Trac #15552, I'd been looking at ZonkEnv in TcHsSyn.

This patch does some minor refactoring

* Make ZonkEnv into a record with named fields, and use them.
  (I'm planning to add a new field, for TyCons, so this prepares
  the way.)

* Replace UnboundTyVarZonker (a higer order function) with the
  simpler and more self-descriptive ZonkFlexi data type, below.
 It's just much more perspicuous and direct, and (I suspect)
 a tiny bit faster too -- no unknown function calls.

data ZonkFlexi   -- See Note [Un-unified unification variables]
  = DefaultFlexi    -- Default unbound unificaiton variables to Any
  | SkolemiseFlexi  -- Skolemise unbound unification variables
                    -- See Note [Zonking the LHS of a RULE]
  | RuntimeUnkFlexi -- Used in the GHCi debugger

There was one knock-on effect in the GHCi debugger -- the
RuntimeUnkFlexi case.  Somehow previously, these RuntimeUnk
variables were sometimes getting SystemNames (and hence
printed as 'a0', 'a1', etc) and sometimes not (and hence
printed as 'a', 'b' etc).  I'm not sure precisely why, but
the new behaviour seems more uniform, so I just accepted the
(small) renaming wibbles in some ghci.debugger tests.

I had a quick look at perf: any changes are tiny.

Reviewers: hvr, bgamari, Azel

Reviewed By: bgamari

Subscribers: thomie, Azel, rwbarton, carter

GHC Trac Issues: #5518, #15525

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

Sadly macOS's C preprocessor gets angry at the sight of multi-line macro
invocations.

In this patch

    commit 6eabb6dd
    Author: Simon Peyton Jones <simonpj@microsoft.com>
    Date:   Tue Dec 15 14:26:13 2015 +0000

    Allow recursive (undecidable) superclasses

I changed (transSuperClasses p) to return only the
superclasses of p, but not p itself. (Previously it always
returned p as well.)

The use of transSuperClasses in TcErrors.warnRedundantConstraints
really needs 'p' in the result -- but I faild to fix this
call site, and instead crippled the test for Trac #10100.

This patch sets things right

* Accomodates the API change
* Re-enables T10100
* And thereby fixes Trac #11474

In error message generation we were using the wrong
type constructor in inst_head.  Result: the type became
ill-kinded, and that sent the compiler into a loop.

A separate patch fixes the loop. This patch fixes the
actual bug -- Trac #15473.

I also improved the "occurs more often" error message
a bit.  But it's still pretty terrible:

    * Variable ‘a’ occurs more often
      in the type family application ‘Undefined’
      than in the instance head ‘LetInterleave xs t ts is y z’

It looks like nonsense, but all becomes clear if you use
-fprint-explicit-kinds.  Really we should fix this by spotting
when invisible arguments are involved and at least suggesting
-fprint-explicit-kinds.

In these two functions
  * TcIface.toIfaceAppTyArgsX
  * Type.piResultTys
we take a type application (f t1 .. tn) and try to find
its kind. It turned out that, if (f t1 .. tn) was ill-kinded
the function would go into an infinite loop.

That's not good: it caused the loop in Trac #15473.

This patch doesn't fix the bug in #15473, but it does turn the
loop into a decent panic, which is a step forward.

This reverts commit 1cc9061f.

This appears to break a clean build with certain versions of
`ld.gold`. See
https://phabricator.haskell.org/rGHC1cc9061fce42#132967.

This reverts commit 2693eb11.

This patch isn't ready yet, see D5051.

This adds a new primop called traceBinaryEvent# that takes the length
of binary data and a pointer to the data, then emits it to the eventlog.

There is some example code that uses this primop and the new event:

* [traceBinaryEventIO][1] that calls `traceBinaryEvent#`

* [A patch to ghc-events][2] that parses the new `EVENT_USER_BINARY_MSG`

There's no corresponding issue on Trac but it was discussed at
ghc-devs [3].

[1] https://github.com/maoe/ghc-trace-events/blob
    /fb226011ef1f85a97b4da7cc9d5f98f9fe6316ae/src/Debug/Trace/Binary.hs#L29)
[2] https://github.com/maoe/ghc-events/commit
    /239ca77c24d18cdd10d6d85a0aef98e4a7c56ae6)
[3] https://mail.haskell.org/pipermail/ghc-devs/2018-May/015791.html

Reviewers: bgamari, erikd, simonmar

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

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

FIxes #15189.

Reviewers: hvr, bgamari, simonmar, simonpj

Reviewed By: simonpj

Subscribers: simonpj, rwbarton, thomie, carter

GHC Trac Issues: #15189

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

Reviewers: hvr, bgamari, simonmar, jrtc27

Reviewed By: bgamari

Subscribers: alpmestan, rwbarton, thomie, carter

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

Reviewers: hvr, bgamari, monoidal

Reviewed By: monoidal

Subscribers: monoidal, rwbarton, thomie, carter

GHC Trac Issues: #15350

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

Currently ap_0_fast doesn't maintain the invariant for PAP fun fields
which says if the closure can be tagged, it should be. This is checked
by `Sanity.c:checkPAP` and correctly implemented by `genautoapply`.

This causes sanity check failures when we have a profiling code like

    f = {-# SCC scc #-} g

where g is a PAP or a FUN, and `scc` is different than the current cost
centre.

Test Plan: Slow validate (not done yet)

Reviewers: simonmar, bgamari, erikd

Reviewed By: simonmar

Subscribers: rwbarton, carter

GHC Trac Issues: #15508

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

In a previous attempt (c6cc93bc) I had
tried aligning to 8 bytes under the assumption that the problem was that
the_gc_thread, a StgWord8[], wasn't being aligned to 8-bytes as the
gc_thread struct would expect. However, we actually need even stronger
alignment due to the alignment attribute attached to gen_workspace,
which claims it should be aligned to a 64-byte boundary.

This fixes #15482.

Reviewers: erikd, simonmar

Reviewed By: simonmar

Subscribers: rwbarton, carter

GHC Trac Issues: #15482

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

Add an additional line to the output of +RTS --info.  It shows the value
of the flag -with-rtsopts provided at compile/link time.

Test Plan: make test TESTS="T15261a T15261b"

Reviewers: hvr, erikd, dfeuer, thomie, austin, bgamari, simonmar, osa1,
monoidal

Reviewed By: osa1, monoidal

Subscribers: osa1, rwbarton, carter

GHC Trac Issues: #15261

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

This drastically cuts down on the number of Haddock warnings when making
docs for `base`.  Plus this means more actual links end up in the docs!
Also fixed other small mostly markup issues in the documentation along
the way.

This is a docs-only change.

Reviewers: hvr, bgamari, thomie

Reviewed By: thomie

Subscribers: thomie, rwbarton, carter

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

If `findIndices` is marked INLINE in `Data.OldList`, then the unfolded
versions of `elemIndex` and `findIndex` included in the interface file
are unfusible (even though `findIndices` itself remains fusible).  By
marking it INLINABLE instead, elemIndex` and `findIndex` will fuse
properly.

Test Plan: make TEST=T15426

Reviewers: hvr, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, carter

GHC Trac Issues: #15426

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