GitLab

This fixes #12584, where wildcard patterns were snuck into an
expression, which then crashed the typechecker in TcExpr since EWildPats
aren't supposed to appear in the AST after renaming.

The problem was that `rnTopSpliceDecl` failed to check for errors from
`rnSplice` (as done by other callers to `rnSplice`).

Thanks to Shayan for reporting this!

Reviewers: simonpj, austin

Reviewed By: simonpj

Subscribers: simonpj, thomie

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

GHC Trac Issues: #12584

This patch implements choice (3) of comment:14 on Trac #12660.
It cures an infinite loop (caused by the creation of an infinite
type) in in compiling the 'singletons' package.

See Note [Add derived shadows only for Wanteds] in TcSMonad.

A rule with a phase specification trying to match on a constructor with
a wrapper will fail to match, as the wrapper will be inlined by then.
The fact that it works in the other case is also mostly by accident.
(Split into two test cases so that regressions with regard what works so
far are caught.)

which test a few variants of rules involving constructors, including
nullary constructors, constructors with wrappers, and unsaturated of
constructors.

At the moment, all the rules work as expected, despite GHC’s compile
time warnings when called with -Wall.

These ones test the variations in coment:15 of the ticket

With my latest commits

  76a5477b Move zonking out of tcFamTyPats
  b255ae7b Orient improvement constraints better

perf has improved slightly for T1969:

allocs:    733M -> 26M
residency: 43M  -> 41M

I don't know exactly why, but hey, it's good

In tcFamTyPats we were zonking from the TcType world to the
Type world, ready to build the results into a CoAxiom (which
should have no TcType stuff.  But the 'thing_inside' for
tcFamTyPats also must be zonked, and that zonking must have
the ZonkEnv from the binders zonked tcFamTyPats.

Ugh.  This caused an assertion failure (with DEBUG on) in
RaeBlobPost and TypeLevelVec, both in tests/dependent, as
shown in Trac #12682.  Why it hasn't shown up before now
is obscure to me.

So I moved the zonking stuff out of tcFamTyPats to its
three call sites, where we can do it all together. Very
slightly longer, but much more robust.

This patch fixes an infinite loop in the constraint solver,
shown up by Trac #12522.

The solution is /very/ simple: just reverse the orientation of the
derived constraints arising from improvement using type-family
injectivity.  I'm not very proud of the fix --- it seems fragile
--- but it has the very great merit of simplicity, and it works
fine.

See Note [Improvement orientation] in TcInteract, and some
discussion on the Trac ticket.

Test Plan: View updated documentation?

Reviewers: austin, hvr, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

GHC Trac Issues: #12672

Nursery chunks help reduce the cost of GC when capabilities are unevenly
loaded, by ensuring that we use more of the available nursery.

The rationale for enabling this at -A16m is that any negative effects
due to loss of cache locality are less likely to be an issue at -A16m
and above.  It's a conservative guess.  If we had a lot of benchmark
data we could probably do better.

Results for nofib/parallel at -N4 -A32m with and without -n4m:

```
------------------------------------------------------------------------
        Program           Size    Allocs   Runtime   Elapsed  TotalMem
------------------------------------------------------------------------
   blackscholes           0.0%     -9.5%     -9.0%    -15.0%     -2.2%
          coins           0.0%     -4.7%     -3.6%     -0.6%    -13.6%
         mandel           0.0%     -0.3%     +7.7%    +13.1%     +0.1%
        matmult           0.0%     +1.5%    +10.0%     +7.7%     +0.1%
          nbody           0.0%     -4.1%     -2.9%     0.085      0.0%
         parfib           0.0%     -1.4%     +1.0%     +1.5%     +0.2%
        partree           0.0%     -0.3%     +0.8%     +2.9%     -0.8%
           prsa           0.0%     -0.5%     -2.1%     -7.6%      0.0%
         queens           0.0%     -3.2%     -1.4%     +2.2%     +1.3%
            ray           0.0%     -5.6%    -14.5%     -7.6%     +0.8%
       sumeuler           0.0%     -0.4%     +2.4%     +1.1%      0.0%
------------------------------------------------------------------------
            Min           0.0%     -9.5%    -14.5%    -15.0%    -13.6%
            Max           0.0%     +1.5%    +10.0%    +13.1%     +1.3%
 Geometric Mean          +0.0%     -2.6%     -1.3%     -0.5%     -1.4%
```

Not conclusive, but slightly better.  This matters a lot more when you
have more cores.

Test Plan: validate, nofib/paralel

Reviewers: niteria, ezyang, nh2, trofi, austin, erikd, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

GHC Trac Issues: #9221

Setting a -N value that is too large has a dramatic negative effect on
performance, but the new -qn flag can mitigate the worst of the effects
by limiting the number of GC threads.

So now, if you don't explcitly set +RTS -qn, and you set -N larger than
the number of cores (or use setNumCapabilities to do the same), we'll
default -qn to the number of cores.

These are the results from nofib/parallel on my 4-core (2 cores x 2
threads) i7 laptop, comparing -N8 before and after this change.

```
------------------------------------------------------------------------
        Program           Size    Allocs   Runtime   Elapsed  TotalMem
------------------------------------------------------------------------
   blackscholes          +0.0%     +0.0%    -72.5%    -72.0%     +9.5%
          coins          +0.0%     -0.0%    -73.7%    -72.2%     -0.8%
         mandel          +0.0%     +0.0%    -76.4%    -75.4%     +3.3%
        matmult          +0.0%    +15.5%    -26.8%    -33.4%     +1.0%
          nbody          +0.0%     +2.4%     +0.7%     0.076      0.0%
         parfib          +0.0%     -8.5%    -33.2%    -31.5%     +2.0%
        partree          +0.0%     -0.0%    -60.4%    -56.8%     +5.7%
           prsa          +0.0%     -0.0%    -65.4%    -60.4%      0.0%
         queens          +0.0%     +0.2%    -58.8%    -58.8%     -1.5%
            ray          +0.0%     -1.5%    -88.7%    -85.6%     -3.6%
       sumeuler          +0.0%     -0.0%    -47.8%    -46.9%      0.0%
------------------------------------------------------------------------
            Min          +0.0%     -8.5%    -88.7%    -85.6%     -3.6%
            Max          +0.0%    +15.5%     +0.7%    -31.5%     +9.5%
 Geometric Mean          +0.0%     +0.6%    -61.4%    -63.1%     +1.4%
```

Test Plan: validate, nofib/parallel benchmarks

Reviewers: niteria, ezyang, nh2, austin, erikd, trofi, bgamari

Reviewed By: trofi, bgamari

Subscribers: thomie

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

GHC Trac Issues: #9221

When trying to build arm64-apple-iso, the build fell over `strdup`, as
the arm64-apple-ios build did not fall into `darwin_HOST_OS`, and would
need `ios_HOST_OS`.

This diff tries to clean up PosixSource.h, instead of layering another
define on top.

As we use `strnlen` in sources that include PosixSource.h, and `strnlen`
is defined in POSIX.1-2008, the `_POSIX_C_SOURCE` and `_XOPEN_SOURCE`
are increased accordingly.

Furthermore the `_DARWIN_C_SOURCE` (required for `u_char`, etc. used in
sysctl.h) define is moved into `OSThreads.h` alongside a similar ifdef
for freebsd.

Test Plan: Build on all supported platforms.

Reviewers: austin, simonmar, erikd, kgardas, bgamari

Reviewed By: simonmar, erikd, kgardas, bgamari

Subscribers: Phyx, hvr, thomie

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

GHC Trac Issues: #12624

When trying to profile a plugin, ghc mysteriously segfaulted.  Upon
closer examination the segfault happend due to a `->prevStack` lookup
on a NULL pointer.

A new CostCentre: Unknown is introduced that is set, if ccsapp and
ccsfn are of equal depth (e.g. 0), and do not have a common CostCentre
in their stacks.

Reviewers: bgamari, simonmar, austin, erikd

Reviewed By: simonmar

Subscribers: Phyx, thomie

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

Test Plan: validate

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

GHC Trac Issues: #12673

- interaction between backpack and export list refactoring
  introduced a few syntax errors, and constructor arity mismatches
- CPP macro used in backpack was not accepted by clang because of
  extraneous whitespace
Signed-off-by: Csongor Kiss <kiss.csongor.kiss@gmail.com>

Reviewers: austin, bgamari, mpickering

Reviewed By: mpickering

Subscribers: thomie

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

The target of this patch is exports such as:

```
module Foo ( T(A, B, C) ) where
```

Essentially this patch makes sure that we use the correct lookup functions in order
to lookup the names in parent-children export lists. This change
highlighted the complexity of this small part of GHC which accounts for
the scale.

This change was motivated by wanting to
remove the `PatternSynonym` constructor from `Parent`. As with all these
things, it quickly spiraled out of control into a much larger refactor.

Reviewers: simonpj, goldfire, bgamari, austin

Subscribers: adamgundry, thomie

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

GHC Trac Issues: #11970

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

It turns out that we don't really need to be able to
extract a ComponentId from UnitId, except in one case.
So compress UnitId into a single FastString.

The one case where we do need the ComponentId is when
we are compiling an instantiated version of a package;
we need the ComponentId to look up the indefinite
version of this package from the database.  So now we
just pass it in as an argument -this-component-id.

Also: ghc-pkg now no longer will unregister a package if
you register one with the same package name, if the
instantiations don't match.

Cabal submodule update which tracks the same data type
change.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Summary:
This patch implements Backpack for GHC.  It's a big patch but I've tried quite
hard to keep things, by-in-large, self-contained.

The user facing specification for Backpack can be found at:

    https://github.com/ezyang/ghc-proposals/blob/backpack/proposals/0000-backpack.rst

A guide to the implementation can be found at:

    https://github.com/ezyang/ghc-proposals/blob/backpack-impl/proposals/0000-backpack-impl.rst

Has a submodule update for Cabal, as well as a submodule update
for filepath to handle more strict checking of cabal-version.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: simonpj, austin, simonmar, bgamari, goldfire

Subscribers: thomie, mpickering

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

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

When looking up flags, we make sure to lookup the non-deprecated flags first
by ordering the list of flags.

Reviewers: bgamari, austin, mpickering

Reviewed By: mpickering

Subscribers: mpickering, thomie

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

GHC Trac Issues: #12574

This fixes the leak with `setProgArgv`. The problem was
that `setProgArgv` would not free the objects pointed
to by `prog_argc`, `prog_argv` when the globals were
changed resulting in a leak.

The only strictly necessary change is in `rts/RtsFlags.c`, but
the code in `System.Environment` was a bit confusing and not
exception safe, so I refactored it.

Test Plan: ./validate

Reviewers: simonmar, ezyang, austin, hvr, bgamari, erikd

Subscribers: thomie

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

GHC Trac Issues: #12664

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

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

these actually are complete, but due to the use of pattern guards, the
compiler does not see that. Refactor the code that it does.

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

Summary:
Keeping a promise I made to Simon to clean up these modules.

This change splits up the massive `TcDeriv` and `TcGenDeriv` modules into
somewhat more manageable pieces. The new modules are:

* `TcGenFunctor`: This contains the deriving machinery for `Functor`,
  `Foldable`, and `Traversable` (which all use the same underlying algorithm).
* `TcDerivInfer`: This is the new home for `inferConstraints`,
  `simplifyInstanceContexts`, and related functions, whose role is to come up
  with the derived instance context and subsequently simplify it.
* `TcDerivUtils`: This is a grab-bag module that contains several
  error-checking utilities originally in `TcDeriv`, as well as some functions
  that `TcDeriv` and `TcDerivInfer` both need.

The end result is that `TcDeriv` is now less than 1,600 SLOC (originally 2,686
SLOC), and `TcGenDeriv` is now about 2,000 SLOC (originally 2,964).

In addition, this also implements a couple of tiny refactorings:

* I transformed `type Condition = (DynFlags, TyCon) -> Validity` into
  `type Condition = DynFlags -> TyCon -> Validity`
* I killed the `DerivSpecGeneric` constructor for `DerivSpecMechanism`, and
  merged its functionality into `DerivSpecStock`. In addition,
  `hasStockDeriving` now contains key-value pairs for `Generic` and `Generic1`,
  so they're no longer treated as an awkward special case in `TcDeriv`.

Test Plan: ./validate

Reviewers: simonpj, austin, bgamari

Reviewed By: simonpj

Subscribers: thomie, mpickering

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

This was (accidentally?) introduced in 465c6c5d

See Note [Constraints and errors] in TcRnMonad.  This
patch fixes Trac #12124 in quite a neat way.