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

Ben Gamari authored 7 years ago and Ben Gamari committed 7 years ago

Test Plan: Validate

Reviewers: alpmestan

Reviewed By: alpmestan

Subscribers: alpmestan, leftaroundabout, rwbarton, thomie, carter

GHC Trac Issues: #14925

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

While investigating #14947, I noticed that the `barf`ed
error message in `push()` doesn't print out the closure type that
causes it to crash. Let's do so.

Reviewers: bgamari, erikd, simonmar

Reviewed By: bgamari

Subscribers: alexbiehl, rwbarton, thomie, carter

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

voanhduy1512 authored 7 years ago and Ben Gamari committed 7 years ago

Accroding to
https://git.haskell.org/ghc.git/commitdiff/49672659113371c3bee691e6d913d
f8e6f60a1d8,
`-Wredundant-constraints` is no longer turn on by default.

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

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

Adam Gundry authored 7 years ago and Ben Gamari committed 7 years ago

Test Plan: new test overloadedrecflds/should_fail/T14953

Reviewers: mpickering, simonpj, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14953

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

Simon Marlow authored 7 years ago and Ben Gamari committed 7 years ago

With a large heap it's possible to build up a lot of finalizers
between GCs.  We've observed GC spending up to 50% of its time running
finalizers.  But there's no reason we have to run finalizers during
GC, and especially no reason we have to block *all* the mutator
threads while *one* GC thread runs finalizers one by one.

I thought about a bunch of alternative ways to handle this, which are
documented along with runSomeFinalizers() in Weak.c.  The approach I
settled on is to have a capability run finalizers if it is idle.  So
running finalizers is like a low-priority background thread. This
requires some minor scheduler changes, but not much.  In the future we
might be able to move more GC work into here (I have my eye on freeing
large blocks, for example).

Test Plan:
* validate
* tested on our system and saw reductions in GC pauses of 40-50%.

Reviewers: bgamari, niteria, osa1, erikd

Reviewed By: bgamari, osa1

Subscribers: rwbarton, thomie, carter

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

Simon Marlow authored 7 years ago and Ben Gamari committed 7 years ago

Test Plan: ci

Reviewers: osa1, bgamari, erikd

Reviewed By: osa1

Subscribers: rwbarton, thomie, carter

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

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

John Ericson authored 7 years ago and Ben Gamari committed 7 years ago

Reviewers: hvr, bgamari, angerman

Reviewed By: angerman

Subscribers: rwbarton, thomie, erikd, carter, angerman

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

Ben Gamari authored 7 years ago and Ben Gamari committed 7 years ago

Reviewers: alpmestan

Reviewed By: alpmestan

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14931

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

Alec Theriault authored 7 years ago and Ben Gamari committed 7 years ago

The user facing TH interface changes are:

  * 'addForeignFile' is renamed to 'addForeignSource'
  * 'qAddForeignFile'/'addForeignFile' now expect 'FilePath's
  * 'RawObject' is now a constructor for 'ForeignSrcLang'
  * 'qAddTempFile'/'addTempFile' let you request a temporary file
    from the compiler.

Test Plan: unsure about this, added a TH test

Reviewers: goldfire, bgamari, angerman

Reviewed By: bgamari, angerman

Subscribers: hsyl20, mboes, carter, simonmar, bitonic, ljli, rwbarton, thomie

GHC Trac Issues: #14298

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

Summary:
At its core, this patch is a simple tweak that allows a user
to write:

```lang=haskell
deriving instance _ => Eq (Foo a)
```

Which is functionally equivalent to:

```lang=haskell
data Foo a = ...
  deriving Eq
```

But with the added flexibility that `StandaloneDeriving` gives you
(namely, the ability to use it anywhere, not just in the same module
that `Foo` was declared in). This fixes #13324, and should hopefully
address a use case brought up in #10607.

Currently, only the use of a single, extra-constraints wildcard is
permitted in a standalone deriving declaration. Any other wildcard
is rejected, so things like
`deriving instance (Eq a, _) => Eq (Foo a)` are currently forbidden.

There are quite a few knock-on changes brought on by this change:

* The `HsSyn` type used to represent standalone-derived instances
  was previously `LHsSigType`, which isn't sufficient to hold
  wildcard types. This needed to be changed to `LHsSigWcType` as a
  result.

* Previously, `DerivContext` was a simple type synonym for
  `Maybe ThetaType`, under the assumption that you'd only ever be in
  the `Nothing` case if you were in a `deriving` clause. After this
  patch, that assumption no longer holds true, as you can also be
  in this situation with standalone deriving when an
  extra-constraints wildcard is used.

  As a result, I changed `DerivContext` to be a proper datatype that
  reflects the new wrinkle that this patch adds, and plumbed this
  through the relevant parts of `TcDeriv` and friends.

* Relatedly, the error-reporting machinery in `TcErrors` also assumed
  that if you have any unsolved constraints in a derived instance,
  then you should be able to fix it by switching over to standalone
  deriving. This was always sound advice before, but with this new
  feature, it's possible to have unsolved constraints even when
  you're standalone-deriving something!

  To rectify this, I tweaked some constructors of `CtOrigin` a bit
  to reflect this new subtlety.

This requires updating the Haddock submodule. See my fork at
https://github.com/RyanGlScott/haddock/commit/067d52fd4be15a1842cbb05f42d9d482de0ad3a7

Test Plan: ./validate

Reviewers: simonpj, goldfire, bgamari

Reviewed By: simonpj

Subscribers: goldfire, rwbarton, thomie, mpickering, carter

GHC Trac Issues: #13324

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

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

I found (when investigating Trac #14955) a binding looking like

   Rec { exported_id = ....big...lcl_id...
       ; lcl_id = exported_id }

but bizarrely 'lcl_id' was chosen as the loop breaker, and never
inlined.  It turned out to be an unintended consequence of the
shortOutIndirections code in SimplCore.  Easily fixed.

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.

This patch fixes Trac #14777, a compiler crash.

There were actually two bugs.

1. In Rules.matchN, I was (consciously) not rename the template binders
   of the rule. Sadly, in rare cases an accidental coincidence of
   uniques could mean that a term variable was mapped to a type
   variable, utterly bogusly.  See "Historical note" in
   Note [Cloning the template binders] in Rules.

   This was hard to find, but easy to fix.

2. The fix to (1) showed up a bug in Unify.hs.  The test in
   Unify.tvBindFlag was previously using the domain of the RnEnv2
   to detect locally-bound variables (e.g. when unifying under
   a forall).  That's fine when teh RnEnv2 starts empty, as it
   does in most entry points.  But the tcMatchTyKisX entry point,
   used from the rule matcher, passes in a non-empty RnEnv2 (by
   design).  Now the domain of the RnEnv doesn't idenfity those
   locally-bound variables any more :-(.

   Solution: extend UmEnv with a new field um_skols, to capture
   the skolems directly.  Simple, easy, works.

This patch implements GHC Proposal #94, described here
   https://github.com/ghc-proposals/ghc-proposals/pull/94

The effect is simply to lift a totally-undocumented restriction to
unidirecional pattern synonyms, namely that they can't have as-patterns
or n+k patterns.

The fix is easy: just remove the checks.

I also took the opportunity to improve the manual entry for
the semantics of pattern matching for pattern synonyms.

Summary:
Before, we were using `isLiftedTypeKind` in `reifyType`
before checking if a type was `Constraint`. But as it turns out,
`isLiftedTypeKind` treats `Constraint` the same as `Type`, so every
occurrence of `Constraint` would be reified as `Type`! To make things
worse, the documentation for `isLiftedTypeKind` stated that it
treats `Constraint` //differently// from `Type`, which simply isn't
true.

This revises the documentation for `isLiftedTypeKind` to reflect
reality, and defers the `isLiftedTypeKind` check in `reifyType` so
that it does not accidentally swallow `Constraint`.

Test Plan: make test TEST=T14869

Reviewers: goldfire, bgamari

Reviewed By: goldfire

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14869

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

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.

This reverts commit 2d4bda2e.

- Add some comments
- Remove $s as they complicate desugarer output for no reason
- Remove an indirection, case_negative is now main

Ben Gamari authored 7 years ago and Ben Gamari committed 7 years ago

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

Ben Gamari authored 7 years ago and Ben Gamari committed 7 years ago

Subscribers: rwbarton, thomie, carter

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

Ben Gamari authored 7 years ago and Ben Gamari committed 7 years ago

Reviewers: hvr

Subscribers: rwbarton, thomie, erikd, carter

GHC Trac Issues: #14910

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

Matthew Pickering authored 7 years ago and Ben Gamari committed 7 years ago

Runs another specialisation pass towards the end of the optimisation
pipeline. This can catch specialisation opportunities which arose from
the previous specialisation pass or other inlining.

You might want to use this if you are you have a type class method
which returns a constrained type. For example, a type class where one
of the methods implements a traversal.

It is not enabled by default or any optimisation level. Only by
manually enabling the flag `-flate-specialise`.

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

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

Douglas Wilson authored 7 years ago and Ben Gamari committed 7 years ago

There should be no change in the output of the '+RTS -s' (summary)
report, or the 'RTS -t' (one-line) report.

All data shown in the summary report is now shown in the machine
readable report.

All data in RTSStats is now shown in the machine readable report.

init times are added to RTSStats and added to GHC.Stats.

Example of the new output:
```
 [("bytes allocated", "375016384")
 ,("num_GCs", "113")
 ,("average_bytes_used", "148348")
 ,("max_bytes_used", "206552")
 ,("num_byte_usage_samples", "2")
 ,("peak_megabytes_allocated", "6")
 ,("init_cpu_seconds", "0.001642")
 ,("init_wall_seconds", "0.001027")
 ,("mut_cpu_seconds", "3.020166")
 ,("mut_wall_seconds", "0.757244")
 ,("GC_cpu_seconds", "0.037750")
 ,("GC_wall_seconds", "0.009569")
 ,("exit_cpu_seconds", "0.000890")
 ,("exit_wall_seconds", "0.002551")
 ,("total_cpu_seconds", "3.060452")
 ,("total_wall_seconds", "0.770395")
 ,("major_gcs", "2")
 ,("allocated_bytes", "375016384")
 ,("max_live_bytes", "206552")
 ,("max_large_objects_bytes", "159344")
 ,("max_compact_bytes", "0")
 ,("max_slop_bytes", "59688")
 ,("max_mem_in_use_bytes", "6291456")
 ,("cumulative_live_bytes", "296696")
 ,("copied_bytes", "541024")
 ,("par_copied_bytes", "493976")
 ,("cumulative_par_max_copied_bytes", "104104")
 ,("cumulative_par_balanced_copied_bytes", "274456")
 ,("fragmentation_bytes", "2112")
 ,("alloc_rate", "124170795")
 ,("productivity_cpu_percent", "0.986838")
 ,("productivity_wall_percent", "0.982935")
 ,("bound_task_count", "1")
 ,("sparks_count", "5836258")
 ,("sparks_converted", "237")
 ,("sparks_overflowed", "1990408")
 ,("sparks_dud ", "0")
 ,("sparks_gcd", "3455553")
 ,("sparks_fizzled", "390060")
 ,("work_balance", "0.555606")
 ,("n_capabilities", "4")
 ,("task_count", "10")
 ,("peak_worker_count", "9")
 ,("worker_count", "9")
 ,("gc_alloc_block_sync_spin", "162")
 ,("gc_alloc_block_sync_yield", "0")
 ,("gc_alloc_block_sync_spin", "162")
 ,("gc_spin_spin", "18840855")
 ,("gc_spin_yield", "10355")
 ,("mut_spin_spin", "70331392")
 ,("mut_spin_yield", "61700")
 ,("waitForGcThreads_spin", "241")
 ,("waitForGcThreads_yield", "2797")
 ,("whitehole_gc_spin", "0")
 ,("whitehole_lockClosure_spin", "0")
 ,("whitehole_lockClosure_yield", "0")
 ,("whitehole_executeMessage_spin", "0")
 ,("whitehole_threadPaused_spin", "0")
 ,("any_work", "1667")
 ,("no_work", "1662")
 ,("scav_find_work", "1026")
 ,("gen_0_collections", "111")
 ,("gen_0_par_collections", "111")
 ,("gen_0_cpu_seconds", "0.036126")
 ,("gen_0_wall_seconds", "0.036126")
 ,("gen_0_max_pause_seconds", "0.036126")
 ,("gen_0_avg_pause_seconds", "0.000081")
 ,("gen_0_sync_spin", "21")
 ,("gen_0_sync_yield", "0")
 ,("gen_1_collections", "2")
 ,("gen_1_par_collections", "1")
 ,("gen_1_cpu_seconds", "0.001624")
 ,("gen_1_wall_seconds", "0.001624")
 ,("gen_1_max_pause_seconds", "0.001624")
 ,("gen_1_avg_pause_seconds", "0.000272")
 ,("gen_1_sync_spin", "3")
 ,("gen_1_sync_yield", "0")
 ]
```

Test Plan: Ensure that one-line and summary reports are unchanged.

Reviewers: bgamari, erikd, simonmar, hvr

Reviewed By: simonmar

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14660

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

John Ericson authored 7 years ago and Ben Gamari committed 7 years ago

Reviewers: angerman, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

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

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

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

Test Plan: make slow

Reviewers: bgamari, erikd, simonmar

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #12870

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

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

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

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

Reviewers: bgamari, hvr, RyanGlScott

Reviewed By: RyanGlScott

Subscribers: RyanGlScott, rwbarton, thomie, erikd, carter

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

Chaitanya Koparkar authored 7 years ago and Ben Gamari committed 7 years ago

Previously, the Renamer would turn any fully qualified Template Haskell
name into a corresponding fully qualified `RdrName`. But this is not
what we want for built-in syntax, as it produces unnecessarily qualified
names (eg. GHC.Types.[], GHC.Tuple.(,) etc.).

Test Plan: ./validate

Reviewers: RyanGlScott, bgamari, goldfire

Reviewed By: RyanGlScott, bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #13776

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

Originally, we compared the key lists, which was kind of silly.
Then I changed it to something fancier ... and also silly.
This is much more reasonable, should be faster, and is nice and
clear.

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

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

Michal Terepeta authored 7 years ago and Ben Gamari committed 7 years ago

`Hoopl.Graph` has almost exactly the same function, so let's use that.
Also, use `IntMap.alter` to make it more efficient.

Also switch `Hoopl` to use strict maps.

Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com>

Test Plan: ./validate

Reviewers: bgamari, simonmar

Reviewed By: bgamari

Subscribers: dfeuer, rwbarton, thomie, carter

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

Ben Gamari authored 7 years ago and Ben Gamari committed 7 years ago

Summary:
get/setAllocationCounter didn't take into account allocations in the
current block. This was known at the time, but it turns out to be
important to have more accuracy when using these in a fine-grained
way.

Test Plan:
New unit test to test incrementally larger allocaitons.  Before I got
results like this:

```
+0
+0
+0
+0
+0
+4096
+0
+0
+0
+0
+0
+4064
+0
+0
+4088
+4056
+0
+0
+0
+4088
+4096
+4056
+4096
```

Notice how the results aren't always monotonically increasing.  After
this patch:

```
+344
+416
+488
+560
+632
+704
+776
+848
+920
+992
+1064
+1136
+1208
+1280
+1352
+1424
+1496
+1568
+1640
+1712
+1784
+1856
+1928
+2000
+2072
+2144
```

Reviewers: hvr, erikd, simonmar, jrtc27, trommler

Reviewed By: simonmar

Subscribers: trommler, jrtc27, rwbarton, thomie, carter

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

Ben Gamari authored 7 years ago and Ben Gamari committed 7 years ago

This is required by D4288. However, this only handles i386; we will
likely also need to do the same for PPC and SPARC, lest they break when
D4288 is re-merged.

Test Plan: Validate

Reviewers: simonmar

Reviewed By: simonmar

Subscribers: rwbarton, thomie, carter

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

Peter Trommler authored 7 years ago and Ben Gamari committed 7 years ago

Support for signed conversion from 32 bit to 64 bit
integers is required by D4363.

Test Plan: validate (perhaps also on SPARC)

Reviewers: simonmar, bgamari, kgardas, jrtc27

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

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