| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These are asymptotically better and convey the intent
a bit better.
Test Plan: ./validate
Reviewers: simonpj, bgamari, austin, goldfire
Reviewed By: bgamari
Subscribers: rwbarton, thomie, simonmar
Differential Revision: https://phabricator.haskell.org/D3455
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TcSimplify.decideQuantification was doing the Wrong Thing when
"growing" the type variables to quantify over. We were trying to do
this on a tyvar set where we'd split off the dependent type varaibles;
and we just got it wrong. A kind variable wasn't being generalised
properly, with confusing knock on consequences.
All this led to Trac #13371 and Trac #13393.
This commit tidies it all up:
* The type TcDepVars is renamed as CandidateQTvs;
and splitDepVarsOfType to candidateQTyVarsOfType
* The code in TcSimplify.decideQuantification is simpler.
It no longer does the tricky "grow" stuff over TcDepVars.
Instead it use ordinary VarSets (thereby eliminating the
nasty growThetaTyVarsDSet) and uses that to filter the
result of candidateQTyVarsOfType.
* I documented that candidateQTyVarsOfType returns the type
variables in a good order in which to quantify, and rewrote
it to use an accumulator pattern, so that we would predicatably
get left-to-right ordering.
In doing all this I also made UniqDFM behave a little more nicely:
* When inserting an element that is there already, keep the old tag,
while still overwriting with the new value.
* This means that when doing udfmToList we get back elements in the
order they were originally inserted, rather than in reverse order.
It's not a big deal, but in a subsequent commit I use it to improve
the order of type variables in inferred types.
All this led to a lot of error message wibbles:
- changing the order of quantified variables
- changing the order in which instances are listed in GHCi
- changing the tidying of variables in typechecker erors
There's a submodule update for 'array' because one of its tests
has an error-message change.
I may not have associated all of them with the correct commit.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The functions that were causing warnings were deprecated in containers
0.5 and GHC is already using containers 0.5.9.1.
Test Plan: validate
Reviewers: rwbarton, bgamari, hsyl20, austin, dfeuer
Reviewed By: dfeuer
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D3036
|
| |
|
|
|
|
|
| |
This documents nondeterminism in code generation and removes
the nondeterministic ufmToList function. In the future someone
will have to use nonDetUFMToList (with proper explanation)
or pprUFMWithKeys.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This impacts at least the order in which version macros are
generated. It's pretty hard to track what kind of nondeterminism
is benign and this should have no performance impact as the number
of packages should be relatively small.
Test Plan: ./validate
Reviewers: simonmar, austin, bgamari, ezyang
Reviewed By: ezyang
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2308
GHC Trac Issues: #4012
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This isn't strictly necessary for deterministic ABIs.
The results of eltsHpt are consumed in two ways:
1) they determine the order of linking
2) if you track the data flow all the family instances get put in
FamInstEnvs, so the nondeterministic order is forgotten.
3) same for VectInfo stuff
4) same for Annotations
The problem is that I haven't found a nice way to do 2. in
a local way and 1. is nice to have if we went for deterministic
object files. Besides these maps are keyed on ModuleNames so they
should be small relative to other things and the overhead should
be negligible.
As a bonus we also get more specific names.
Test Plan: ./validate
Reviewers: bgamari, austin, hvr, ezyang, simonmar
Reviewed By: simonmar
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2300
GHC Trac Issues: #4012
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This lets us kill fsEnvElts function which is nondeterministic.
We also get better guarantees than just comments.
We don't do lookups, but I believe a set is needed for deduplication.
Test Plan: ./validate
Reviewers: bgamari, mpickering, austin, simonmar
Reviewed By: simonmar
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2297
GHC Trac Issues: #4012
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Deriving `Typeable` has been a no-op since GHC 7.10, and now that we
require 7.10+ to build GHC, we can remove all the redundant `deriving Typeable`
statements in GHC.
Test Plan: ./validate
Reviewers: goldfire, austin, hvr, bgamari
Reviewed By: austin, hvr, bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2260
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This kills two instances of varSetElems that turned out to be
nondeterministic. I've tried to untangle this before, but it's
a bit hard with the fixDs in the middle. Fortunately I now have
a test case that proves that we need determinism here.
Test Plan: ./validate, new testcase
Reviewers: simonpj, simonmar, austin, bgamari
Reviewed By: bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2258
GHC Trac Issues: #4012
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The order inert_model and intert_eqs fold affects the order that the
typechecker looks at things. I've been able to experimentally confirm
that the order of equalities and the order of the model matter for
determinism. This is just a straigthforward replacement of
nondeterministic VarEnv for deterministic DVarEnv.
Test Plan: ./validate
Reviewers: simonpj, goldfire, austin, bgamari, simonmar
Reviewed By: simonmar
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2232
GHC Trac Issues: #4012
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We need the order of specialized binds and rules to be deterministic,
so we use a deterministic set here.
Test Plan: ./validate
Reviewers: simonmar, bgamari, austin, simonpj
Reviewed By: simonpj
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2197
GHC Trac Issues: #4012
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In the past the canonical way for constructing an SDoc string literal was the
composition `ptext . sLit`. But for some time now we have function `text` that
does the same. Plus it has some rules that optimize its runtime behaviour.
This patch takes all uses of `ptext . sLit` in the compiler and replaces them
with calls to `text`. The main benefits of this patch are clener (shorter) code
and less dependencies between module, because many modules now do not need to
import `FastString`. I don't expect any performance benefits - we mostly use
SDocs to report errors and it seems there is little to be gained here.
Test Plan: ./validate
Reviewers: bgamari, austin, goldfire, hvr, alanz
Subscribers: goldfire, thomie, mpickering
Differential Revision: https://phabricator.haskell.org/D1784
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This implements the ideas originally put forward in
"System FC with Explicit Kind Equality" (ICFP'13).
There are several noteworthy changes with this patch:
* We now have casts in types. These change the kind
of a type. See new constructor `CastTy`.
* All types and all constructors can be promoted.
This includes GADT constructors. GADT pattern matches
take place in type family equations. In Core,
types can now be applied to coercions via the
`CoercionTy` constructor.
* Coercions can now be heterogeneous, relating types
of different kinds. A coercion proving `t1 :: k1 ~ t2 :: k2`
proves both that `t1` and `t2` are the same and also that
`k1` and `k2` are the same.
* The `Coercion` type has been significantly enhanced.
The documentation in `docs/core-spec/core-spec.pdf` reflects
the new reality.
* The type of `*` is now `*`. No more `BOX`.
* Users can write explicit kind variables in their code,
anywhere they can write type variables. For backward compatibility,
automatic inference of kind-variable binding is still permitted.
* The new extension `TypeInType` turns on the new user-facing
features.
* Type families and synonyms are now promoted to kinds. This causes
trouble with parsing `*`, leading to the somewhat awkward new
`HsAppsTy` constructor for `HsType`. This is dispatched with in
the renamer, where the kind `*` can be told apart from a
type-level multiplication operator. Without `-XTypeInType` the
old behavior persists. With `-XTypeInType`, you need to import
`Data.Kind` to get `*`, also known as `Type`.
* The kind-checking algorithms in TcHsType have been significantly
rewritten to allow for enhanced kinds.
* The new features are still quite experimental and may be in flux.
* TODO: Several open tickets: #11195, #11196, #11197, #11198, #11203.
* TODO: Update user manual.
Tickets addressed: #9017, #9173, #7961, #10524, #8566, #11142.
Updates Haddock submodule.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I will need them for the future determinism fixes.
Test Plan: ./validate
Reviewers: simonpj, goldfire, bgamari, austin, hvr, simonmar
Reviewed By: simonpj, simonmar
Subscribers: osa1, thomie
Differential Revision: https://phabricator.haskell.org/D1537
GHC Trac Issues: #4012
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This implements `DVarSet`, a deterministic set of Vars, with an
interface very similar to `VarSet` with a couple of functions missing.
I will need this in changes that follow, one of them will be about
changing the type of the set of Vars that `RuleInfo` holds to make the
free variable computation deterministic.
Test Plan:
./validate
I can add new tests if anyone wants me to.
Reviewers: simonpj, simonmar, austin, bgamari
Reviewed By: simonmar, bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1487
GHC Trac Issues: #4012
|
|
|
When generating dictionary let binds in dsTcEvBinds we may
end up generating them in arbitrary order according to Unique order.
Consider:
```
let $dEq = GHC.Classes.$fEqInt in
let $$dNum = GHC.Num.$fNumInt in ...
```
vs
```
let $dNum = GHC.Num.$fNumInt in
let $dEq = GHC.Classes.$fEqInt in ...
```
The way this change fixes it is by using `UniqDFM` - a type of
deterministic finite maps of things keyed on `Unique`s. This way when
you pull out evidence variables corresponding to type-class dictionaries
they are in deterministic order.
Currently it's the order of insertion and the way it's implemented is by
tagging the values with the time of insertion.
Test Plan:
I've added a new test case to reproduce the issue.
./validate
Reviewers: ezyang, simonmar, austin, simonpj, bgamari
Reviewed By: simonmar, simonpj, bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1396
GHC Trac Issues: #4012
|
