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.

- T12962: just fix function locations
- scc003: reorder cost centres, cost centre `f.(...)` renamed to `f.x'`

Reviewers: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14704

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

Provide information about paths more likely to be taken in the cmm files
used by the rts.

This leads to slightly better assembly being generated.

Reviewers: bgamari, erikd, simonmar

Subscribers: alexbiehl, rwbarton, thomie, carter

GHC Trac Issues: #14672

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

... in CmmSink

For code like:
f 1 = e1
f 7 = e2
f _ = e3

We can treat it as a sparse jump table, check if we are outside of the
range in one direction first and then start checking the values.

GHC currently does this by checking for x>7, then x <= 7 and at last x
== 1.

This patch changes this such that we only compare for equality against
the two values and jump to the default if non are equal.

The resulting code is both faster and smaller.
wheel-sieve1 improves by 4-8% depending on problem size.

This implements the idea from #14644

Reviewers: bgamari, simonmar, simonpj, nomeata

Reviewed By: simonpj, nomeata

Subscribers: nomeata, simonpj, rwbarton, thomie, carter

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

Currently, error messages that germane to GADT constructors
put the source span at only the first character in the constructor,
leading to insufficient caret diagnostics. This can be easily fixed
by using a source span that spans the entire constructor, instead of
just the first character.

Test Plan: make test TEST=T14719

Reviewers: alanz, bgamari, simonpj

Reviewed By: alanz, simonpj

Subscribers: simonpj, goldfire, rwbarton, thomie, carter

GHC Trac Issues: #14719

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

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

On Windows we use the function `win32AllocStack` to do stack
allocations in 4k blocks and insert a stack check afterwards
to ensure the allocation returned a valid block.

The problem is this function does something that by C semantics
is pointless. The stack allocated value can never escape the
function, and the stack isn't used so the compiler just optimizes
away the entire function body.

After considering a bunch of other possibilities I think the simplest
fix is to just disable optimizations for the function.

Alternatively inline assembly is an option but the stack check function
doesn't have a very portable name as it relies on e.g. `libgcc`.

Thanks to Sergey Vinokurov for helping diagnose and test.

Test Plan: ./validate

Reviewers: bgamari, erikd, simonmar

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14669

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

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

This adds a parser-level switch to have 'LINE' and 'COLUMN'
pragmas lexed into actual tokens (as opposed to updating the
position information in the parser).

'lexTokenStream' is the only place where this option is enabled.

Reviewers: bgamari, alexbiehl, mpickering

Reviewed By: mpickering

Subscribers: alanz, rwbarton, thomie, carter

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

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

Reasons to remove:
- It's confusing - we already have a widely used `Unique` module in
  `basicTypes/` that defines a newtype called `Unique`
- `Hoopl.Unique` is not actually used much

I've also moved the `Unique{Map,Set}` from `Hoopl.Unique` to
`Hoopl.Collections` to keep things together. But that module is also a
bit funny - it defines two type-classes that have only one instance
each. So we should probably either remove them or use them more
widely... In any case, that will be a separate change.

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

Test Plan: ./validate

Reviewers: bgamari, simonmar

Reviewed By: bgamari

Subscribers: kavon, rwbarton, thomie, carter

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

Previously `splitEnv` worked like this:

    > splitEnv "foo:::bar::baz:"
    ["foo","","","bar","","baz",""]

with this patch:

    > splitEnv working_dir "foo:::bar:baz:"
    ["foo",working_dir,working_dir"bar","baz",working_dir]

This fixes #14695, where having a trailing `:` in the env variable
caused ghci to pass empty `-B` parameter to `gcc`, which in turned
caused the next parameter (`--print-file-name`) to be considered as the
argument to `-B`. As a result ghci did not work.

The `working_dir` argument is to have a similar behavior with POSIX:
according to chapter 8.3 zero-length prefix means current working
directory.

Reviewers: hvr, bgamari, AndreasK, simonmar

Reviewed By: bgamari, AndreasK, simonmar

Subscribers: AndreasK, rwbarton, thomie, carter

GHC Trac Issues: #14695

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

Matthías Páll Gissurarson authored 7 years ago and Ben Gamari committed 7 years ago

This is an initial attempt at tackling the issue of how to order the
suggestions provided by the valid substitutions checker, by sorting
them by creating a graph of how they subsume each other. We'd like to
order them in such a manner that the most "relevant" suggestions are
displayed first, so that the suggestion that the user might be looking
for is displayed before more far-fetched suggestions (and thus also
displayed when they'd otherwise be cut-off by the
`-fmax-valid-substitutions` limit). The previous ordering was based on
the order in which the elements appear in the list of imports, which I
believe is less correlated with relevance than this ordering.

A drawback of this approach is that, since we now want to sort the
elements, we can no longer "bail out early" when we've hit the
`-fmax-valid-substitutions` limit.

Reviewers: bgamari, dfeuer

Reviewed By: dfeuer

Subscribers: dfeuer, rwbarton, thomie, carter

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