GitLab

This renames VisibilityFlag from

> data VisibilityFlag = Visible | Specified | Invisible

to

> data ArgFlag = Required | Specified | Inferred

The old name was quite confusing, because both Specified
and Invisible were invisible! The new names are hopefully clearer.

* Replaced 2.11's *TBA* with *May 2016*
* Removed an outdated TODO comment
* Removed lines which incorrectly stated that some strictness-related
  functions had been removed (they have been deprecated instead)

Summary: Add more Notes and signposts across the codebase to help navigation.

Test Plan: validate

Reviewers: goldfire, simonpj, austin, ezyang, hvr, bgamari, erikd

Subscribers: thomie

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

Summary:
From a suggestion by @goldfire: clean up the message types, so that
rather than one Message type with all the messages, we have a separate
THMessage type for messages sent back to GHC during TH execution.  At
the same time I also removed the QDone/QFailed/QException messages
into their own type, and made the result type of RunTH more accurate.

Test Plan: validate

Reviewers: goldfire, ezyang, austin, niteria, bgamari, erikd

Subscribers: thomie, goldfire

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

Fixes
   T10697_decided_1.run  T10697_decided_1 [exit code non-0] (ext-interp)
   T10697_decided_2.run  T10697_decided_2 [exit code non-0] (ext-interp)
   T10697_decided_3.run  T10697_decided_3 [exit code non-0] (ext-interp)

This patch fixes Trac #12216 and #12127.  The 'combine' function
in 'imp_occ_env' in RnNames.filterImports checked for an empty
field-selector list, which was (a) unnecessary and (b) wrong.

I've elaborated the comments.

This does NOT fix #11959 which is related but not the same
(it concerns bundling of pattern synonyms).

Very minor

In an instance declaration when you don't specify the code for a
method, GHC fills in from the default binding in the class.
The type of the default method can legitmiately be ambiguous ---
see Note [Default methods in instances] in TcInstDcls --- so
typechecking it can be tricky.

Trac #12220 showed that although we were dealing with that ambiguity
for /vanilla/ default methods, we were not doing so for /generic/
default methods.  Moreover we were dealing with it clumsily, by
generating post-typechecked code.

This patch fixes the bug AND deletes code!  We now use the same code
path for both vanilla and generic default methods; and generate
/pre-typechecked/ code in both cases.  The key trick is that we can use
Visible Type Application to deal with the ambiguity, which wasn't
possible before.  Hooray.

There is a small hit to performance in compiler/perf/T1969 which
consists of nothing BUT instance declarations with several default
methods to fill, which we now have to typecheck. The actual hit is
from 724 -> 756 or 4% in that extreme example.  Real world programs
have vastly fewer instance decls.

See the user's guide entry or the Note [TcRnExprMode] in TcRnDriver.

Test cases: ghci/scripts/T{10963,11975}

Test cases:
  typecheck/should_compile/T11974
  typecheck/should_fail/T11974b

After 35d1564c: Provide Uniquable version of SCC we
can remove this. We want to remove it because when used
it can introduce unnecessary nondeterminism.

GHC Trac: #4012

We want to remove the `Ord Unique` instance because there's
no way to implement it in deterministic way and it's too
easy to use by accident.

We sometimes compute SCC for datatypes whose Ord instance
is implemented in terms of Unique. The Ord constraint on
SCC is just an artifact of some internal data structures.
We can have an alternative implementation with a data
structure that uses Uniquable instead.

This does exactly that and I'm pleased that I didn't have
to introduce any duplication to do that.

Test Plan:
./validate
I looked at performance tests and it's a tiny bit better.

Reviewers: bgamari, simonmar, ezyang, austin, goldfire

Subscribers: thomie

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

GHC Trac Issues: #4012

Summary:
This patch uses collectArgsTicks instead of collectArgs to test that
StaticPtr only occurs at the top of RHSs of top-level expressions.

Ticks introduced by -fhpc would interfere otherwise.

Test Plan: ./validate

Reviewers: thomie, austin, goldfire, bgamari, simonpj

Reviewed By: simonpj

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

GHC Trac Issues: #12207

In reviewing the fix to Trac #12130 I found the wild-card
fill-in code for ".." notation in record constructions hard
to understand.  It went to great contortions (including the
find_tycon code) to allow
    data T = C { x, y :: Int }
    f x = C { .. }
to expand to
    f x = C { x = x, y = y }
where 'y' is an /imported function/!  That seems way over the top
for what record wildcards are supposed to do.

So I have narrowed the record-wildcard expansion to include only
/locally-bound/ variables; i.e. not top level, and certainly not
imported.

I don't think anyone is using record wildcards in this bizarre way, so
I don't expect any fallout. Even if there is, you can easily
initialise fields with eponymous but imported values by hand.

An intermediate position would be to allow /local/ top-level
definitions.  But I doubt anyone is doing that either.

Let's see if there's any fallout.  It's a local change, easy to
revert, so I've just gone ahead to save everyone's time.

In Trac #11948 I added the warning
    -Wsimplifiable-class-constraints
which warns if the class constraints in a type signature are
simplifiable.

But in fact the fragility it warns about only happens with
NoMonoLocalBinds, so this patch switches off the warning if
you have MonoLocalBinds (and suggests using it in the error
message).

See Note [Simplifiable given constraints] in TcValidity.

lookupGRE_Name should return either zero or one GREs, never
several. This is a consequence of INVARIANT 1 on GlobalRdrEnv.

So it's better if it returns a Maybe; the panic on multiple results
is put in one place, instead of being scattered or ignored.

Just refactoring, no change in behaviour

This patch fixes Trac #12175, another delicate corner case of
Note [Instance and Given overlap] in TcInteract.

In #12175 we were not expanding given superclasses eagerly
enough. It was easy to fix, and is actually rather neater than
before.

See Note [Eagerly expand given superclasses] in TcCanonical.
The main change is to move the eager expansion of given superclasses
to canClassNC.

We don't need the FamInstEnvs argument any more.
Just a tiny refactor.

Fixes Trac #12163.  Pretty simple.

The `Ord Module` instance currently uses `Unique`s for comparison.
We don't want to use the `Unique` order because it can introduce
nondeterminism.
This switches `Ord ModuleName` and `Ord UnitId` to use lexicographic
ordering making `Ord Module` deterministic transitively.

I've run `nofib` and it doesn't make a measurable difference.

See also Note [ModuleEnv determinism and performance].

This fixes #12191 - the regression, that the previous version of this
patch had.

Test Plan:
./validate
run nofib: P112

Reviewers: simonmar, bgamari, austin

Subscribers: thomie

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

GHC Trac Issues: #4012, #12191

The warning for reference:
```
rts/RaiseAsync.c: In function ‘throwToMsg’:

rts/SMPClosureOps.h:65:0: error:
     error: inlining failed in call to ‘lockClosure’: call is unlikely
and code size would grow

rts/RaiseAsync.c:305:0: error:  error: called from here

rts/SMPClosureOps.h:65:0: error:
     error: inlining failed in call to ‘lockClosure’: call is unlikely
and code size would grow
```

This warning triggers on `gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-16)`
and it doesn't trigger with new GCCs.

Test Plan: build ghc/rts

Reviewers: bgamari, simonmar, austin

Subscribers: thomie

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

Summary:
Background:
* sizeExpr was calculating expressions like ((e `cast` T) x) wrongly
* Fixing it caused regressions in compile performance, and one nofib
  program (k-nucleotide)

I managed to fix the source of the compiler regressions.  I think it was
due to traceTc not being inlined, which I fixed in a more robust way by
putting an export list on TcRnMonad.

The k-nucleotide regression is more difficult.  I don't think anything
is actually going wrong, but this program has been highly tuned and is
quite sensitive to changing in inlining behaviour.  I managed to recover
most of the performance by manual lambda-lifting which makes it a bit
less fragile, but the end result was a bit slower.  I don't think this
is disastrous, the program is pretty horrible to begin with and we could
probably make a faster one by starting from scratch.

Test Plan: validate, nofib

Reviewers: simonpj, bgamari, niteria, austin, erikd

Subscribers: thomie

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

GHC Trac Issues: #11564