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

See `Note [Recompute abi-depends]` for more information.

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

Test Plan: `./validate`

Reviewers: bgamari, ezyang

Reviewed By: bgamari

Subscribers: tdammers, juhp, carter, alexbiehl, shlevy, cocreature,
rwbarton, thomie

GHC Trac Issues: #14381

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

(cherry picked from commit 1cdc14f9)

Summary:
We were unconditionally updating the nursery pointers to be
`nurseries[cap->no]`, but when using nursery chunks this might be
wrong. This manifested as a later assertion failure in allocate().

Test Plan: new test case

Reviewers: bgamari, niteria, erikd

Subscribers: thomie, carter

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

(cherry picked from commit 4cb5595e)

Herbert Valerio Riedel authored 6 years ago and Ben Gamari committed 6 years ago

A common complaint with the new package environment files feature is
that it's not obvious when package environments have been picked up.
This patch applies the same strategy that was already used for `.ghci` files
(which exhibit similar potential for confusion, c.f. #11389) to package
environment files.

For instance, this new notification looks like below for a GHCi invocation which
loads both, a GHCi configuration as well as a package environment:

  GHCi, version 8.5.20180512: http://www.haskell.org/ghc/  :? for help
  Loaded package environment from /tmp/parsec-3.1.13.0/.ghc.environment.x86_64-linux-8.5.20180512
  Loaded GHCi configuration from /home/hvr/.ghci
  Prelude>

Addresses #15145

Reviewed By: bgamari, angerman

GHC Trac Issues: #15145

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

(cherry picked from commit 00049e2d)

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

Before this patch, the pprUnwindwExpr function computed the length of
by the following assembly fragment:

	.uleb128 1f-.-1
	<expression data>
1:

That is, to compute the length, it takes the difference of the label 1
and the address of the .uleb128 directive, and subtracts 1.

In #15068 it was reported that `as` from binutils 4.30 has trouble with
evaluating the `.` part of the expression. However, there is actually a
problem with the expression, if the length of the data ever becomes
larger than 128: In that case, the .uleb128 directive will emit more
than 1 byte, and the computed length will be wrong.

The present patch changes the assembly fragment to use two labels,
which fixes both these problems.

	.uleb128 2f-1f
1:
	<expression data>
2:

Test Plan: validate

Reviewers: bgamari, osa1

Reviewed By: bgamari

Subscribers: thomie, carter

GHC Trac Issues: #15068

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

(cherry picked from commit 358b5080)

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

commit b2ff5dde "Fix #15038"
added new stable closure 'absentSumFieldError_closure' to
base package. This closure is used in rts package.

Unfortunately the symbol was not explicitly exported and build
failed on windows as:

```
"inplace/bin/ghc-stage1" -o ...hsc2hs.exe ...
rts/dist/build/libHSrts.a(RtsStartup.o): In function `hs_init_ghc':

rts/RtsStartup.c:272:0: error:
     undefined reference to `base_ControlziExceptionziBase_absentSumFieldError_closure'
    |
272 |     getStablePtr((StgPtr)absentSumFieldError_closure);
    | ^

```

This change adds 'absentSumFieldError_closure' to explicit export
into libHSbase.def.

Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
(cherry picked from commit 79bbb23f)

We introduce a new Id for unused pointer values in unboxed sums that is
not CAFFY. Because the Id is not CAFFY it doesn't make non-CAFFY
definitions CAFFY, fixing #15038.

To make sure anything referenced by the new id will be retained we get a
stable pointer to in on RTS startup.

Test Plan: Passes validate

Reviewers: simonmar, simonpj, hvr, bgamari, erikd

Reviewed By: simonmar

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #15038

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

(cherry picked from commit b2ff5dde)

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

This was blatantly wrong due to copy-paste blindness:

 * labels were shadowed, which GHC doesn't warn about(!), resulting in
   plainly wrong behavior
 * the sharing check was omitted
 * the wrong closure layout was being used

Moreover, the test wasn't being run due to its primitive dependency, so
I didn't even notice. Sillyness.

Test Plan: install `primitive`, `make test TEST=compact_small_array`

Reviewers: simonmar, erikd

Reviewed By: simonmar

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #13857.

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

(cherry picked from commit 12deb9a9)

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

The Mathjax CDN no longer exists. Use CDNJS instead.

See #15006.

Test Plan: Build HTML users guide, see whether math is rendered.

Reviewers: alpmestan

Reviewed By: alpmestan

Subscribers: thomie, carter

GHC Trac Issues: #15006

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

(cherry picked from commit 803178a5)

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.

(cherry picked from commit 5ab8094e)

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

as helpfully outlined by SPJ.

This commit copies a small bit code from `SetLevels` which could
reasonably be put in `Id` as `zapAllIdinfo`; I did not do this to make
merging this commmit into `ghc-8.4` easier.

If this commit gets merged, then presumably after commit
3f59d380 (test case) and
ae0cff0a (other fixes to Exitify.hs).

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

(cherry picked from commit 3cfb12d8)

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

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

(cherry picked from commit 3f59d380)

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

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)

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

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)

Frank Steffahn authored 7 years ago and Ben Gamari committed 6 years ago

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)