| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
It is a self-recursive function so will always be the loop-breaker
and hence never able to be inlined. It is dubious whether the INLINABLE
pragma will ever help as it is not a very polymorphic function
but some specialisation could occur.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
I've run into situations where I need deterministic `tyVarsOfType` and
this implementation achieves that and also brings an algorithmic
improvement. Union of two `VarSet`s takes linear time the size of the
sets and in the worst case we can have `n` unions of sets of sizes
`(n-1, 1), (n-2, 1)...` making it quadratic.
One reason why we need deterministic `tyVarsOfType` is in `abstractVars`
in `SetLevels`. When we abstract type variables when floating we want
them to be abstracted in deterministic order.
Test Plan: harbormaster
Reviewers: simonpj, goldfire, austin, hvr, simonmar, bgamari
Reviewed By: simonmar
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1468
GHC Trac Issues: #4012
|
