Edward Z. Yang authored 7 years ago and Ben Gamari committed 7 years ago

See comment in Packages for more details.

Fixes #14717.

Signed-off-by: Edward Z. Yang <ezyang@fb.com>

Test Plan: validate

Reviewers: snoyberg, taylorfausak, bgamari

Reviewed By: snoyberg, taylorfausak, bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14717

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

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

Test Plan: Validate

Reviewers: erikd, simonmar

Reviewed By: simonmar

Subscribers: rwbarton, thomie, carter

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

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

Test Plan: Validate

Reviewers: erikd, simonmar

Reviewed By: simonmar

Subscribers: rwbarton, thomie, carter

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

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

Test Plan: ./validate

Reviewers: goldfire, bgamari, simonmar

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

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

I've explained most of the rationale in a new Note.
I'd happily add a test for this, but the difference is only
visible in run time, allocations remain more or less the same.

FWIW running `generateModules` from #14693 with DEPTH=16, WIDTH=30
finishes in `23s` before, and `11s` after.

Test Plan: ./validate

Reviewers: simonpj, simonmar, bgamari

Reviewed By: simonpj

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14693

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

* Clarify the representation of sums without fields.
* Try to improve language, clarity, and examples.

Fixes #14752

Reviewers: osa1, bgamari

Reviewed By: osa1

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14752

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

Trac #14226 noted that the C-- CBE pass frequently fails to
common up semantically identical blocks due to the differences in local
register naming. These patches fixed this by making the pass consider
equality up to alpha-renaming.

However, the new logic failed to consider the possibility that local
register naming *may* matter across multiple blocks. This lead to the
regression #14754. I'll need to do a bit of thinking on a proper
solution to this but in the meantime I'm reverting all four patches.

This reverts commit a27056f9.
This reverts commit 6f990c54.
This reverts commit 9aa73892.
This reverts commit 7920a7d9.

Commit 193664d4 added a
special caseRule for `dataToTag`, but this transformation completely
broke when `dataToTag` was applied to somewith with a type headed by
a data family, leading to #14680. For now at least, the simplest
solution is to simply not apply this transformation when the type is
headed by a data family.

Test Plan: make test TEST=T14680

Reviewers: simonpj, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14680

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

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

GCC's __sync primitives apparently "usually" imply a full barrier,
meaning they can be used to emulate the more precise C11 atomics albeit
with a loss of efficiency. This restores compatibility with GCC 4.4.

This partially reverts commit 59de2909.

Test Plan: Validate on Centos

Reviewers: hvr, simonmar, trommler

Subscribers: rwbarton, thomie, erikd, carter

GHC Trac Issues: #14244

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

Reviewers: bgamari

Subscribers: rwbarton, thomie, carter

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

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

There weas lots of historical cruft to be found here. The `export
SHELLOPTS` breaks on NixOS due to bash syntax in the gcc wrapper script.

Reviewers: hvr

Subscribers: rwbarton, thomie, carter

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

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

Test Plan: Validate

Subscribers: rwbarton, thomie, carter

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

This function is called in lots of places, so if it
every fails it's good to know from where it was called.

This is Simon's patch, part of his `wip/T2893` branch.

Test Plan: Validate

Subscribers: rwbarton, thomie, carter

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

CircleCI seems to suggest that the cost center ordering is wrong in the prof
way. I'm beginning to wonder whether there is some non-determinism here. If only
I know what this test was supposed to be testing.

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

It seems that most uses of these folds should be strict left folds
(I could only find a single place that benefits from a right fold).
So this removes the existing `setFold`/`mapFold`/`mapFoldWihKey`
replaces them with:
- `setFoldl`/`mapFoldl`/`mapFoldlWithKey` (strict left folds)
- `setFoldr`/`mapFoldr` (for the less common case where a right fold
  actually makes sense, e.g., `CmmProcPoint`)

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

Test Plan: ./validate

Reviewers: bgamari, simonmar

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter, kavon

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

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

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

This allows you to see the output immediately after desugaring
but before any optimisation.

I've wanted this for some time, but I was triggered into action
by Trac #13032 comment:9.

Interestingly, the change means that with -dcore-lint we will
now Lint the output before the very simple optimiser;
and this showed up Trac #14749.  But that's not the fault
of -ddump-ds-preopt!

There's a 6% reduction in allocation on T3064.  I think it's due to

  commit e4ab65bd
  Author: Tobias Dammers <tdammers@gmail.com>
  Date:   Wed Jan 31 21:39:45 2018 -0500

      Optimize coercionKind (Trac #11735)

I'm not certain -- but, hey, it's good news

This patch is comments only, plus a minor refactor that
does not change behaviour.

It just records an idea I had for reducing kick-out in the type
constraint-solver.

See Note [Eliminate younger unification variables] in TcUnify.

Sadly, it didn't improve perf, so I've put it aside, leaving
some breadcrumbs for future generations of GHC hackers.

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

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

Reviewers: simonpj, goldfire, bgamari

Reviewed By: simonpj

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #11735

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

This prevents the register being picked up as a scratch register.
Otherwise the allocator would be free to use it before a call. This
fixes #14619.

Test Plan: ci, repro case on #14619

Reviewers: bgamari, Phyx, erikd, simonmar, RyanGlScott, simonpj

Reviewed By: Phyx, RyanGlScott, simonpj

Subscribers: simonpj, RyanGlScott, Phyx, rwbarton, thomie, carter

GHC Trac Issues: #14619

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

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

Test Plan: validate

Reviewers: simonmar, erikd

Reviewed By: simonmar

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14725

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

Currently, any standalone-derived instance must satisfy the
property that the tycon of the data type having an instance being
derived for it must be either a normal ADT tycon or a data family
tycon. But there are several other primitive tycons—such as `(->)`,
`Int#`, and others—which cannot have standalone-derived instances
(via the `anyclass` strategy) as a result of this check! See
https://ghc.haskell.org/trac/ghc/ticket/13154#comment:8 for an
example of where this overly conservative restriction bites.

Really, this validity check only makes sense in the context of
`stock` deriving, where we need the property that the tycon is that
of a normal ADT or a data family in order to inspect its data
constructors. Other deriving strategies don't require this validity
check, so the most sensible way to fix this error is to move the
logic of this check into `cond_stdOK`, which is specific to
`stock` deriving.

This makes progress towards fixing (but does not entirely fix)

Test Plan: make test TEST=T13154a

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #13154

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

takano-akio authored 7 years ago and Ben Gamari committed 7 years ago

This patch implements the BlockArguments extension, as proposed at
https://github.com/ghc-proposals/ghc-proposals/pull/90. It also
fixes #10855 as a side-effect.

This patch adds a large number of shift-reduce conflicts to the parser.
All of them concern the ambiguity as to where constructs like `if` and
`let` end. Fortunately they are resolved correctly by preferring shift.

The patch is based on @gibiansky's ArgumentDo implementation (D1219).

Test Plan: ./validate

Reviewers: goldfire, bgamari, alanz, mpickering

Reviewed By: bgamari, mpickering

Subscribers: Wizek, dfeuer, gibiansky, rwbarton, thomie, mpickering, carter

GHC Trac Issues: #10843, #10855

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

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

When using the :add command in haxlsh/ghci, a module/file that can't
be found is still added to the list of targets, resulting in an error
message for the bad module/file for every subsequent usage of the
command. The add command should verify that the module/file can be
found before adding it to the list of targets.

Also add a ":show targets" command to show the currently added list of
commands, and an ":unadd" command to remove a target.

Test Plan:
Add a new GHCi testcase that checks that :add doesn't remember either
files or modules that could not be found, and that both the new :show
and :unadd commands work as expected.

Reviewers: simonmar, bgamari

Reviewed By: simonmar

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14676

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

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

Currently runtime keeps hold to 4*used_memory. This includes, in
particular, nursery, which can be quite large on multiprocessor
machines: 16 CPUs x 64Mb each is 1GB. Multiplying it by 4 means whatever
actual memory usage is, runtime will never release memory under 4GB, and
this is quite excessive for processes which only need a lot of memory
shortly (think building data structures from large files).

This diff makes multiplier to apply only to GC-managed memory, leaving
all "static" allocations alone.

Test Plan: make test TEST="T14702"

Reviewers: bgamari, erikd, simonmar

Reviewed By: simonmar

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14702

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

Move build logic into a dedicated bash script, avoiding repetitive
bash invocations. Furthermore, disable pacman update step as it breaks
things in non-predictable ways.

Looks right to me.

Arguably the warning should just be disabled for this test to eliminate
unnecessary wiggle in the future.

We use GHC's toolchain anyways.

These two tests have been failing on CircleCI.

Trac #14732 was a perpelexing bug in which -fdefer-typed-holes
caused a mysterious type error in a RULE.  This turned out to
be because we are more aggressive about creating implications
when deferring (see TcUnify.implicationNeeded), and the rule
mechanism hadn't caught up.

This fixes it.

We already prioritise equalities when solving, but
Trac #14723 showed that we were not doing so consistently
enough, and as a result the type checker could go into a loop.
Yikes.

See Note [Prioritise equalities] in TcSMonad.

Fixng this bug changed the solve order enough to demonstrate
a problem with fundeps: Trac #14745.

runTcSWithEvBinds does some unification, so the zonkWC
must be after, not before!  Yikes.  An outright bug.

This fixes Trac #14715.