GitLab

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

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

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

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

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

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

This is an obvious optimisation whose overhead is neglectable but
which significantly simplifies the common uses of `compareByteArrays#`
which would otherwise require to make *careful* use of
`reallyUnsafePtrEquality#` or (equally fragile) `byteArrayContents#`
which can result in less optimal assembler code being generated.

Test Plan: carefully examined generated cmm/asm code; validate via phab

Reviewers: alexbiehl, bgamari, simonmar

Reviewed By: bgamari, simonmar

Subscribers: rwbarton, thomie, carter

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

Adding the ability to parse likely flags in Cmm allows better codegen
for cmm files.

Test Plan: ci

Reviewers: bgamari, simonmar

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14672

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

It's better to fall through to the likely case than to jump to it.

We optimize for this in CmmContFlowOpt when likely:False.
This commit extends the logic there to handle cases with likely:True
as well.

Test Plan: ci

Reviewers: bgamari, simonmar

Reviewed By: bgamari

Subscribers: simonmar, alexbiehl, rwbarton, thomie, carter

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

Test Plan: Validate

Reviewers: hvr, dfeuer

Reviewed By: dfeuer

Subscribers: dfeuer, rwbarton, thomie, carter

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

The GHC-side `getNameToInstancesIndex` filters out incorrectly some
instances because it is not aware of what modules are visible. Using
`runTcInteractive` means that `ie_visible` gets initialized to a one
module set containing some dummy GHCi module. This is clearly not the
module set we want to check against to see if a given orphan instance
is visible or not.

In fact, GHC has no way of knowing what we want that module set to be
since it doesn't know ahead of time which modules Haddock is making its
docs for. The fix is just to pass that set in as an argument.

Bumps haddock submodule.

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: duog, alexbiehl, rwbarton, thomie, carter

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

Subscribers: rwbarton, thomie, carter

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

Ideally, I'd like to do

    type EvTerm = CoreExpr

and the type checker builds the evidence terms as it goes. This failed,
becuase the evidence for `Typeable` refers to local identifiers that are
added *after* the typechecker solves constraints. Therefore, `EvTerm`
stays a data type with two constructors: `EvExpr` for `CoreExpr`
evidence, and `EvTypeable` for the others.

Delted `Note [Memoising typeOf]`, its reference (and presumably
relevance) was removed in 8fa4bf9a.

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

See Note [Lone variables] in CoreUnfold and
Note [exprIsExpandable] in CoreUtils.

Helpfully pointed out by Matthew Pickering in Trac #14688

Nofib results are good:

--------------------------------------------------------------------------------
        Program           Size    Allocs   Runtime   Elapsed  TotalMem
--------------------------------------------------------------------------------
           anna          +0.1%     +0.3%     0.151     0.151      0.0%
         awards          +0.0%     -0.2%     0.001     0.001      0.0%
      compress2          +0.6%     -0.7%     -4.8%     -5.0%     -4.0%
          eliza          +0.0%     -2.4%     0.001     0.001      0.0%
         fulsom          +0.4%    -13.3%     -7.6%     -7.6%   +190.0%
         gamteb          +0.0%     -0.6%     0.062     0.062      0.0%
             gg          +0.1%     -0.4%     0.016     0.016      0.0%
            ida          +0.1%     +0.3%     0.110     0.110      0.0%
          kahan          +0.0%     -0.7%     -0.9%     -0.9%      0.0%
           mate          +0.1%     -5.2%     -4.9%     -4.9%      0.0%
         n-body          +0.0%     -0.2%     -0.3%     -3.0%      0.0%
         pretty          +0.0%     -2.8%     0.000     0.000      0.0%
            scs          +0.0%     -0.2%     +1.6%     +2.4%      0.0%
         simple          +0.4%     -0.2%     -2.3%     -2.3%     -3.4%
        veritas          +0.4%     -1.0%     0.003     0.003      0.0%
           wang          +0.0%     -1.6%     0.165     0.165      0.0%
--------------------------------------------------------------------------------
            Min          -0.0%    -13.3%    -16.2%    -18.8%     -4.0%
            Max          +0.6%     +0.3%     +4.9%     +4.9%   +190.0%
 Geometric Mean          +0.1%     -0.3%     -1.7%     -2.4%     +0.9%

Richard was confused; I hope these comments help.

This gives a 10% allocation improvement on MultiLayerModules.
The idea is to reuse existing tuples, instead of constantly
constructing new ones.

Test Plan: ./validate

Reviewers: simonpj, bgamari

Reviewed By: simonpj, bgamari

Subscribers: rwbarton, thomie, simonmar, carter

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

Not doing so resulted in different uniques being printed on different
environments, as shown in #14703.