GitLab

I needed this instance when debugging, so I thought I'd add
it permanently.

simplifyInstanceContexts used cmpType which is nondeterministic
for canonicalising typeclass constraints in derived instances.
Following changes make it deterministic as explained by the
Note [Deterministic simplifyInstanceContexts].

Test Plan: ./validate

Reviewers: simonmar, goldfire, simonpj, austin, bgamari

Reviewed By: simonpj

Subscribers: thomie

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

GHC Trac Issues: #4012

This is the only call site of `lhs_cmp_type` and we only
care about equality.
`cmpType` is nondeterministic (because `TyCon`s are compared
with Uniques in `cmpTc`), so if we don't have to use it, it's
better not to.

Test Plan: ./validate

Reviewers: simonmar, goldfire, bgamari, austin, simonpj

Reviewed By: simonpj

Subscribers: thomie

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

GHC Trac Issues: #4012

[skip ci]

It was possible for a thread to read invalid memory after a conflict
when multiple threads were synchronising.

I haven't been successful in constructing a test case that triggers
this, but we have some internal code that ran into it.

This suggestion only applies to operators.

In the long discussion on #11432, it was decided that when a type
constructor is parsed as a variable ((--.->) is one example) then in
order to export the type constructor then the user should be required to
use the ExplicitNamespaces keyword.

This was implemented in quite an indirect manner in the renamer. It
is much more direct to enforce this in the parser at the expense of
slighty worse error messages. Further to this, the check in the
renamer was actually slightly wrong. If the variable was in scope
then no error was raised, this was causing panics, see #12026 for an
example.

Reviewers: austin, bgamari

Subscribers: davean, skvadrik, thomie

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

GHC Trac Issues: #12026

Previously I had it so that dv_kvs and dv_tvs didn't
overlap.  Now they can, and quantifyZonkedTyVars
removes the former from the latter.  This is more
economical, and in fact there was a bug where the
invariant wasn't re-established.

It's much easier to allow dv_kvs and dv_kvs to overlap,
and to eliminate the overlap in TcMType.quantifyZonkedTyVars

I committed three patches involving partial type sigs that
are collectively responsible for these error message changes.
The are all just changes to numbering in the pretty-printer.

I didn't bother to partition them between patches -- sorry!

There's a messy bit of tcSimplifyInfer which concerns how
quantify when partial type signatures are involved. This
patch tidies it up a lot.

Notice that decideQuantification and quantify_tvs get
much simpler.  And previously the inferred type of a
function could be cluttered with phantom variables that
were relevant only to the error messgas.

See Note [Quantification and partial signatures].

It turns out that GHC 8.0 would accept entirely bogus
programs like

   f2 :: (True, _) -> Char
   Just f2 = Just (\x->x)

(which is now partial-sigs/should_fail/PatBind3)

This also fixes Trac #9478, test `PatBind2`.

We were failing to emit wild-card hole constraints altogether
in the case of pattern bindings.  Reason: it was done in
tcExtendTyVarEnvFromSig, which isn't called for pattern bindings.

This patch make it work right for both pattern and function
bindings.  Mainly, there is a call to emitWildCardHolds in
tcRhs for both PatBind and FunBind.

I also killed off TcExpr.typeSigCtxt.

We can't define Stg{Int,Word} in terms of {,u}intptr_t because STG
depends on them being the exact same size as void*, and {,u}intptr_t
does not make that guarantee. Furthermore, we also need to define
StgHalf{Int,Word}, so the preprocessor if needs to stay. But we can at
least keep it in a single place instead of repeating it in various
files.

Also define STG_{INT,WORD}{8,16,32,64}_{MIN,MAX} and use it in HsFFI.h,
further reducing the need for CPP in other files.

Reviewers: austin, bgamari, simonmar, hvr, erikd

Subscribers: thomie

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

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

Test Plan: docs only

Reviewers: simonpj, austin, goldfire, bgamari

Subscribers: thomie

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

On x64 Windows `sizeof long` is 4 which could easily overflow
resulting in incorrect heap profiling results. This change does not
affect either Linux or OS X where `sizeof long` == `sizeof ssize_t`
regardless of machine word size.

Test Plan: Validate on Linux and Windows

Reviewers: hsyl20, bgamari, simonmar, austin

Subscribers: thomie

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

[skip ci]

[skip ci]

We add the default method Ids to the global type envt in
tcAddImplicits; and then again in tcInstDcls2 (for reasons
explained there).  But for some reason in the latter case
we added them to the /local/ type envt, via tcExtendLetEnv.

This patch just uses tcExtendGlobalValEnv consistently
for both.

(I found this when reviewing slightly-awkward code from Facundo's
static-form error-message patch; turned out that the awkwardness
came back to this inconsistency in the handling of default
methods.)

The `nat` type was an alias for `unsigned int` with a comment saying
it was at least 32 bits. We keep the typedef in case client code is
using it but mark it as deprecated.

Test Plan: Validated on Linux, OS X and Windows

Reviewers: simonmar, austin, thomie, hvr, bgamari, hsyl20

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

Summary:
foldUFM introduces unnecessary non-determinism that actually
leads to different generated code as explained in
Note [TrieMap determinism].

As we're switching from UniqFM to UniqDFM here you might be
concerned about performance. There's nothing that ./validate
detects. nofib reports no change in Compile Allocations, but
Compile Time got better on some tests and worse on some,
yielding this summary:

        -1 s.d.                -----            -3.8%
        +1 s.d.                -----            +5.4%
        Average                -----            +0.7%

This is not a fair comparison as the order of Uniques
changes what GHC is actually doing. One benefit from making
this deterministic is also that it will make the
performance results more stable.

Full nofib results: P108

Test Plan: ./validate, nofib

Reviewers: goldfire, simonpj, simonmar, austin, bgamari

Reviewed By: simonpj

Subscribers: thomie

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

GHC Trac Issues: #4012

Seems like this should be available in GHC.Exts. Thanks for @carter
for pointing this out.

Test Plan: Validate

Reviewers: rwbarton, hvr, austin

Reviewed By: austin

Subscribers: thomie, carter

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

Test Plan: Validate, expected to fail

Reviewers: goldfire, austin

Reviewed By: austin

Subscribers: thomie

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

GHC Trac Issues: #11959

This fixes #11990.

The current rule is simpler than before: if we encounter an unsolved
constraint that contains any mentions of properly applied `TypeError`,
then we report the type error.

If there are multiple `TypeErrors`, then we just report one of them.

Reviewers: simonpj, bgamari, austin

Reviewed By: simonpj

Subscribers: thomie

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

GHC Trac Issues: #11990

If you already have mkUserGuidePart compiled.

This causes errors with some versions of gcc (4.4.7 here).

This function had some pathalogically bad behaviour: if we had 2 threads
on the current capability and 23 other idle capabilities, we would

* grab all 23 capabilities
* migrate one Haskell thread to one of them
* wake up a worker on *all* 23 other capabilities.

This lead to a lot of unnecessary wakeups when using large -N values.

Now, we

* Count how many capabilities we need to wake up
* Start from cap->no+1, so that we don't overload low-numbered capabilities
* Only wake up capabilities that we migrated a thread to (unless we have
  sparks to steal)

This results in a pretty dramatic improvement in our production system.

+RTS -AL<size> controls the total size of large objects that can be
allocated before a GC is triggered.  Previously this was always just the
value of -A, and the limit mainly existed to prevent runaway allocation
in pathalogical programs that allocate a lot of large objects.  However,
since the limit is shared between all cores, on a large multicore the
default becomes more restrictive, and can end up triggering GC well
before it would normally have been.

Arguably a better default would be A*N, but this is probably excessive.
Adding a flag lets you choose, and I've left the default as it was.

See docs for usage.

This allows the GC to use fewer threads than the number of capabilities.
At each GC, we choose some of the capabilities to be "idle", which means
that the thread running on that capability (if any) will sleep for the
duration of the GC, and the other threads will do its work.  We choose
capabilities that are already idle (if any) to be the idle capabilities.

The idea is that this helps in the following situation:

* We want to use a large -N value so as to make use of hyperthreaded
  cores
* We use a large heap size, so GC is infrequent
* But we don't want to use all -N threads in the GC, because that
  thrashes the memory too much.

See docs for usage.

This is a band-aid; the test suite should not be sensitive to these
messages.

as suggested by carter in #12011.