GitLab

this succeeds on `master` right now, but I confirmed that it fails on
ghc-8.4.1-release.

(cherry picked from commit 3f59d380)

As the CSE transformation traverses the syntax tree, it needs to go past
the lambdas of a join point, and only look for CSE opportunities inside,
as a join point’s lambdas must be preserved. Simple fix; comes with a
Note and a test case.

Thanks to Ryan Scott for an excellently minimized test case, and for
bisecting GHC.

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

(cherry picked from commit ae0cff0a)

Summary:
In D4113, a `FixIOException` data type was added with a
`@since TODO` annotation, but it seems that `TODO` made it out into
`base-4.11` itself. I've (retroactively) fixed this and added an
entry to the `base-4.11` entry in the `changelog`.

Test Plan: Read it

Reviewers: dfeuer, hvr, bgamari

Reviewed By: dfeuer

Subscribers: thomie, carter

GHC Trac Issues: #14356, #15025

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

(cherry picked from commit ce27c7d5)

Reviewers: hvr, bgamari

Subscribers: lelf, thomie, carter

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

(cherry picked from commit 4b831c27)

This takes care of bumping the `base` and `integer-gmp`
minor version numbers in anticipation of a GHC 8.4.2 release.

While I was in town, I also filled in a `@since TODO` Haddock
annotation for `powModSecInteger` in `integer-gmp` with
`1.0.2.0`, and updated the changelog accordingly.

Test Plan: ./validate

Reviewers: hvr, goldfire, bgamari

Reviewed By: bgamari

Subscribers: thomie, carter

GHC Trac Issues: #15025

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

(cherry picked from commit c4814ab6)

Previously, GHC was quite eager to panic whenever it was fed
an archive file when `DYNAMIC_GHC_PROGRAMS=YES`. This ought to be an
explicit error message instead, so this patch accomplishes just that.

Test Plan: make test TEST=T14708

Reviewers: Phyx, hvr, bgamari

Reviewed By: Phyx

Subscribers: thomie, carter

GHC Trac Issues: #9438, #14708, #15032

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

(cherry picked from commit 7613a812)

push() considers BLOCKING_QUEUES to be an invalid closure type which
should never be present on the stack. However, retainClosure made no
accomodation for this and ended up pushing such a closure. This lead
to #14947.

Test Plan: Validate

Reviewers: simonmar, erikd

Reviewed By: simonmar

Subscribers: thomie, carter, RyanGlScott

GHC Trac Issues: #14947

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

(cherry picked from commit d5f6d7a0)

Previously, GHC allowed all of the following:

```lang=haskell
data Foo1 :: Constraint
data family Foo2 :: Constraint
data family Foo3 :: k
data instance Foo3 :: Constraint
```

Yikes! This is because GHC was confusing `Type` with `Constraint`
due to careless use of the `isLiftedTypeKind` function. To respect
this distinction, I swapped `isLiftedTypeKind` out for
`tcIsStarKind`—which does respect this distinction—in the right
places.

Test Plan: make test TEST="T14048a T14048b T14048c"

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: goldfire, rwbarton, thomie, carter

GHC Trac Issues: #14048

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

(cherry picked from commit f748c529)

This patch fixes an outright bug in tcDataKindSig, shown up in Trac
of a data type declaration.  See Note [TyConBinders for the result kind
signature of a data type]

I also took the opportunity to elminate the DataKindCheck argument
and data type from tcDataKindSig, instead moving the check to the
call site, which is easier to understand.

(cherry picked from commit 68149452)

This reverts commit 59d7ee53 and enables
the test for #14052.

(See #14052 for the discussion)

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14052

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

(cherry picked from commit 98c7749c)

The backslash currently in this type signature makes no sense. Without it, the example is fine.

(cherry picked from commit 960cd424)

The pure unifier was building an infinite type, through a defective
occurs check.  So GHC went into an infinite loop.

Reason: we were neglecting the 'kco' part of the type, which
'unify_ty' maintains.  Yikes.

The fix is easy.  I refactored a bit to make it harder to
go wrong in future.

(cherry picked from commit e99fdf77)

The way GHC was handling `DeriveAnyClass` was subtly wrong
in two notable ways:

* In `inferConstraintsDAC`, we were //always// bumping the `TcLevel`
  of newly created unification variables, under the assumption that
  we would always place those unification variables inside an
  implication constraint. But #14932 showed precisely the scenario
  where we had `DeriveAnyClass` //without// any of the generated
  constraints being used inside an implication, which made GHC
  incorrectly believe the unification variables were untouchable.
* Even worse, we were using the generated unification variables from
  `inferConstraintsDAC` in every single iteration of `simplifyDeriv`.
  In #14933, however, we have a scenario where we fill in a
  unification variable with a skolem in one iteration, discard it,
  proceed on to another iteration, use the same unification variable
  (still filled in with the old skolem), and try to unify it with
  a //new// skolem! This results in an utter disaster.

The root of both these problems is `inferConstraintsDAC`. This patch
fixes the issue by no longer generating unification variables
directly in `inferConstraintsDAC`. Instead, we store the original
variables from a generic default type signature in `to_metas`, a new
field of `ThetaOrigin`, and in each iteration of `simplifyDeriv`, we
generate fresh meta tyvars (avoiding the second issue). Moreover,
this allows us to more carefully fine-tune the `TcLevel` under which
we create these meta tyvars, fixing the first issue.

Test Plan: make test TEST="T14932 T14933"

Reviewers: simonpj, bgamari

Reviewed By: simonpj

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14932, #14933

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

(cherry picked from commit 98930426)

Fixes #14740.

Test Plan: make test TEST="14740"

Reviewers: bgamari, simonpj

Reviewed By: simonpj

Subscribers: simonpj, rwbarton, thomie, carter

GHC Trac Issues: #14740

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

(cherry picked from commit ced9fbd3)

For some reason, `axSub0R` was left out of `typeNatCoAxiomRules` in
`TcTypeNats`, which led to disaster when trying to look up `Sub0R` from
an interface file, as demonstrated in #14934.

The fix is simple—just add `axSub0R` to that list. To help prevent
an issue like this happening in the future, I added a
`Note [Adding built-in type families]` to `TcTypeNats`, which
contains a walkthrough of all the definitions in `TcTypeNats` you
need to update when adding a new built-in type family.

Test Plan: make test TEST=T14934

Reviewers: bgamari, simonpj

Reviewed By: simonpj

Subscribers: simonpj, rwbarton, thomie, carter

GHC Trac Issues: #14934

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

(cherry picked from commit c3aea396)

This subtle patch fixes Trac #5129 (again; comment:20
and following).

I took the opportunity to document seq# properly; see
Note [seq# magic] in PrelRules, and Note [seq# and expr_ok]
in CoreUtils.

(cherry picked from commit abaf43d9)

The RULE for bitInteger was trying to constant-fold

    bitInteger 9223372036854775807#

which meant constructing a gigantic Integer at compile
time.  Very bad idea!  Easily fixed.

Fixes Trac #14959, #14962.

(cherry picked from commit efc844f5)

When interpreter is not profiled (see `interpreterProfiled` in
`DynFlags`) bytecode generator generates a NULL pointer as the cost
centre of a `BRK_FUN` instruction:

    let cc | interpreterProfiled dflags = cc_arr ! tick_no
           | otherwise = toRemotePtr nullPtr
    let breakInstr = BRK_FUN (fromIntegral tick_no) (getUnique this_mod) cc
    return $ breakInstr `consOL` code

We now take this into account when disassembling `BRK_FUN`.

Reviewers: bgamari, simonmar, erikd

Subscribers: rwbarton, thomie, carter

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

(cherry picked from commit 8e341013)

Given this program:

    main = do
      f $ do
        a <- return 3
          c <- do
          return 5

GHC previously gave this error message:

    Main.hs:2:7: error:
        Parse error in pattern: do a <- return 3 c
        Possibly caused by a missing 'do'?
      |
    2 |   f $ do
      |       ^^...

What happened is GHC considered the whole `f $ do a <- return 3 c` as a
pattern. When parsed as an expression it becomes an infix application of
`($)`, and GHC checks left and right hand sides before checking if `($)`
is a valid infix constructor name, and shows the first error it got.

If instead we first check if the infix op is valid in pattern context,
the error message becomes much clearer:

    Main.hs:2:3: error:
        Parse error in pattern: f $ do a <- return 3 c
        Possibly caused by a missing 'do'?
      |
    2 |   f $ do
      |   ^^^^^^...

This may not entirely fix #11188 but I think it's an improvement.

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #11188

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

(cherry picked from commit cb6d8589)

Test Plan: `make test TEST=T14925`

Reviewers: hvr, dfeuer

Reviewed By: dfeuer

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14925

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

(cherry picked from commit 20ae19fc)

Manually-written instances and standalone-derived instances
have the benefit of having the `checkValidInstHead` function run over
them, which catches manual instances of built-in types like `(~)` and
`Coercible`. However, instances generated from `deriving` clauses
weren't being passed through `checkValidInstHead`, leading to
confusing results as in #14916.

`checkValidInstHead` also has additional validity checks for language
extensions like `FlexibleInstances` and `MultiParamTypeClasses`. Up
until now, GHC has never required these language extensions for
`deriving` clause, so to avoid unnecessary breakage, I opted to
suppress these language extension checks for `deriving` clauses, just
like we currently suppress them for `SPECIALIZE instance` pragmas.

Test Plan: make test TEST=T14916

Reviewers: goldfire, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14916

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

(cherry picked from commit 20f14b4f)

-g1 removes block information, but it turns out that procs can
refer to block information through parents.
Note [Splitting DebugBlocks] explains the parentage relationship.

Test Plan:
* ./validate
* added a new test

Reviewers: bgamari, simonmar

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14894

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

(cherry picked from commit 0cbb13b3)

Subscribers: rwbarton, thomie, carter

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

(cherry picked from commit d718023e)

Summary:
In commit dbd81f7e, a
regression was inadvertently introduced which caused derived `Read`
instances for record data types with fields ending in a `#` symbol
(using `MagicHash`) would no longer parse on valid output. This
is ultimately due to the same reasons as #5041, as we cannot parse
a field name like `foo#` as a single identifier. We fix this issue
by employing the same workaround as in #5041: first parse the
identifier name `foo`, then then symbol `#`.

This is accomplished by the new `readFieldHash` function in
`GHC.Read`. This will likely warrant a `base-4.11.1.0` release.

Test Plan: make test TEST=T14918

Reviewers: tdammers, hvr, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14918

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

(cherry picked from commit d5577f44)

Reviewers: hvr

Subscribers: rwbarton, thomie, erikd, carter

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

(cherry picked from commit a25b763f)

Summary: OpenIndiana apparently reports a triple of i386-pc-solaris2.11.

Reviewers: hvr

Subscribers: rwbarton, thomie, erikd, carter

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

(cherry picked from commit 4fa077a2a1d6e6e7a45ef03a1075ff3c7dddb23d)

OpenIndiana apparently reports a triple of i386-pc-solaris2.11.

Thanks to Gabor for pointing this out.

This was broken by D3746 and/or D3809, but unfortunately we didn't
notice because CI at the time wasn't building the profiling way.

Test Plan:
```
cd testsuite/test/profiling/should_run
make WAY=ghci-ext-prof
```

Reviewers: bgamari, michalt, hvr, erikd

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14705

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

(cherry picked from commit 488d63d6)

`all_tasks_mutex` should be released before calling `releaseCapability_`
in the parent process as `releaseCapability_` spawns worker tasks in
some cases.

Reviewers: bgamari, erikd, simonmar

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14538

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

(cherry picked from commit e261b852)

Summary:
This came up when trying to build GHC HEAD with nix. We
do not set CCX for integer-gmp when running ./configure. We do
this however for libffi.

The result is, that if CCX is not set, we default to the system
one, of which there might be none (as in nixos's case).  This
will not show on a debian+nix or similar setup, where the system
`cxx` is still in place, and only shows up when the system tries
hard to sandbox everything (even cxx) as nixOS does.

We use `CXX`, which is set to either `clang` or `CC_STAGE1`, and
also usedfor `CC`, similar to what we do for libffi.c

Test Plan: ./validate

Reviewers: bgamari, hvr

Reviewed By: hvr

Subscribers: rwbarton, thomie, carter

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

(cherry picked from commit cf5bc96e)

This reverts f5b275a2
and changes the places that looked for `Lit (MachStr _))`
to use `exprIsMbTickedLitString_maybe` to unwrap ticks as
necessary.
Also updated relevant comments.

Test Plan:
I added 3 new tests that previously reproduced.
GHC HEAD now builds with -g

Reviewers: simonpj, simonmar, bgamari, hvr, goldfire

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14779

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

(cherry picked from commit 5bc195a2)