GitLab

We want to remove varSetElems at the source level because it
might be a source of nondeterminism. I don't think it introduces
nondeterminism here, but it's easy to do the same thing
deterministically for the same price.

instFlexiTcS :: [TKVar] -> TcS (TCvSubst, [TcType])
instFlexiTcS currently gives the range of the produced substitution
as the second element of the tuple, but it's not used anywhere
right now. If it started to be used in the code I'm modifying
it would cause nondeterminism problems.

Test Plan: ./validate

Reviewers: austin, goldfire, bgamari, simonmar, simonpj

Reviewed By: simonpj

Subscribers: thomie

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

GHC Trac Issues: #4012

with changes to nofib-analyse:
 * up-to-date parsing of output lines with recent GHC under
 * a few reporting improvements.

xcrun --find seems like the appropriate choice here. Thanks to Brandon
Allbery for suggesting this.

Previously, the state hack would be implemented in mkLocalId, by looking
at the type, and setting the OneShot flag accordingly.

This patch changes this so that the OneShot flag faithfully represents
what our various analyses found out, and the State Hack is implemented
by adjusting the accessors, in particular isOneShotBndr and
idStateHackOneShotInfo. This makes it easier to understand what's going
on in the analyses, and de-clutters core dumps and interface files.

I don’t expect any change in behaviour, at least not in non-fringe
cases.

varSetElems introduces unnecessary nondeterminism and it was
straighforward to just get a deterministic list.

Test Plan: ./validate

Reviewers: austin, goldfire, bgamari, simonmar, simonpj

Reviewed By: simonpj

Subscribers: thomie

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

GHC Trac Issues: #4012

`varSetElems` introduces unnecessary nondeterminism and we can do
the same thing deterministically for the same price.

Test Plan: ./validate

Reviewers: goldfire, austin, simonmar, bgamari, simonpj

Reviewed By: simonpj

Subscribers: thomie

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

GHC Trac Issues: #4012

The uses of varSetElems in these places are unnecessary and while it
doesn't intruduce non-determinism in the ABI the plan is to get
rid of all varSetElems to get some compile time guarantees.

Test Plan: ./validate

Reviewers: austin, simonmar, bgamari, goldfire, simonpj

Reviewed By: simonpj

Subscribers: thomie

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

GHC Trac Issues: #4012

A microoptimisation in the block allocator.

Make it clearer that the final statement should be exactly
"(return|pure) E".

CPU time is never very accurate, and it broke completely with
-fexternal-interpreter which runs the interpreted computations in a
separate process.

This allows an OS thread to specify which capability it should run on
when it makes a call into Haskell.  It is intended for a fairly
specialised use case, when the client wants to have tighter control over
the mapping between OS threads and Capabilities - perhaps 1:1
correspondence, for example.

varSetElemsWellScoped introduces unnecessary non-determinism in
inferred type signatures.
Removing this instance required changing the representation of
TcDepVars to use deterministic sets.
This is the last occurence of varSetElemsWellScoped, allowing me to
finally remove it.

Test Plan:
./validate
I will update the expected outputs when commiting, some reordering
of type variables in types is expected.

Reviewers: goldfire, simonpj, austin, bgamari

Reviewed By: simonpj

Subscribers: thomie, simonmar

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

GHC Trac Issues: #4012

In 99cd277c, goldfire deleted the Roles9
test, but not its stderr file.

These aren't run very often, because they require external libraries.
https://ghc.haskell.org/trac/ghc/wiki/Building/RunningTests/Running#AdditionalPackages

maessen-hashtab still doesn't compile, QuickCheck api changed.

Update submodule hpc.

Thanks to George Colpitts for the suggestion.

It's possible to get rid of this use site in a local way
and it introduces unneccessary nondeterminism.

Test Plan: ./validate

Reviewers: simonmar, goldfire, austin, bgamari, simonpj

Reviewed By: simonpj

Subscribers: thomie

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

GHC Trac Issues: #4012

This change takes us one step closer to being able to remove
`varSetElemsWellScoped`. The end goal is to make every source
of non-determinism obvious at the source level, so that when
we achieve determinism it doesn't get broken accidentally.

Test Plan: compile GHC

Reviewers: simonmar, goldfire, simonpj, austin, bgamari

Reviewed By: simonpj

Subscribers: thomie

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

GHC Trac Issues: #4012

Grepping reveals that it's not used. I suspect that it isn't useful
anymore.

Test Plan: grep

Reviewers: goldfire, austin, bgamari, simonpj

Reviewed By: simonpj

Subscribers: thomie, simonmar

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

A RULE can have unbound meta-tyvars on the LHS.  Consider
  data T a = C

  foo :: T a -> Int
  foo C = 1

  {-# RULES "myrule"  foo C = 1 #-}

After type checking the LHS becomes (foo alpha (C alpah)) and we do
not want to zap the unbound meta-tyvar 'alpha' to Any, because that
limits the applicability of the rule.  Instead, we want to quantify
over it!

Previously there was a rather clunky implementation of this
quantification, buried in the zonker in TcHsSyn (zonkTvCollecting).

This patch refactors it so that the zonker just turns the meta-tyvar
into a skolem, and the desugarer adds the quantification.  See DsBinds
Note [Free tyvars on rule LHS]. As it happened, the desugarer was
already doing something similar for dictionaries. See DsBinds
Note [Free dictionaries on rule LHS]

No change in functionality, but less cruft.

I found zonkQuantifiedTyVar rather complicated, especially the two
places where we defaulted RuntimeRep variables. This simplifies and
modularises the story.

Refactoring only.

Trac #11941 demonstrated a case where an out-of-scope error also
gave rise to a (bogus and confusing) stage restriction message.

It's caused by the fact that out-of-scope errors do not stop
renaming, but rather return an "unbound name".  We need to
detect this in the stage-restriction test to avoid the double
error.  Easy fix.

Provoked by Trac #11948, this patch adds a new warning to GHC

  -Wsimplifiable-class-constraints

It warns if you write a class constraint in a type signature that
can be simplified by an existing instance declaration.  Almost always
this means you should simplify it right now; type inference is very
fragile without it, as #11948 shows.

I've put the warning as on-by-default, but I suppose that if there are
howls of protest we can move it out (as happened for -Wredundant-constraints.

It actually found an example of an over-complicated context in CmmNode.

Quite a few tests use these weird contexts to trigger something else,
so I had to suppress the warning in those.

The 'haskeline' library has a few occurrences of the warning (which
I think should be fixed), so I switched it off for that library in
warnings.mk.

The warning itself is done in TcValidity.check_class_pred.

HOWEVER, when type inference fails we get a type error; and the error
suppresses the (informative) warning.  So as things stand, the warning
only happens when it doesn't cause a problem.  Not sure what to do
about this, but this patch takes us forward, I think.

This fixes Trac #11947.  See TcSimplify
Note [No defaulting in the ambiguity check]

Now that warnIf takes a "reason", we can test the reason
in warnIf rather than in the caller.  Less code, and less
risk of getting the test and the reason out of sync.

Richard isn't sure why it's there and removing it didn't change
anything.

This is from Simon's suggestion:

* `tyCoVarsOfTypesAcc` is a terrible name for a function with a
  perfectly decent type `[Type] -> FV`. Maybe `tyCoFVsOfTypes`?
  Similarly others

* `runFVList` is also terrible, but also has a decent type.
  Maybe just `fvVarList` (and `fvVarSet` for `runFVSet`).

* `someVars` could be `mkFVs :: [Var] -> FV`.

My validate didn't catch this one; it is fallout
(actually an improvement) from
  353d8a SCC analysis for instances as well as types/classes