| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This commit brings following changes and fixes:
* Implement parseExpr and compileParsedExpr;
* Fix compileExpr and dynCompilerExpr, which returned `()` for empty expr;
* Fix :def and :cmd, which didn't work if `IO` or `String` is not in scope;
* Use GHCiMonad instead IO in :def and :cmd;
* Clean PrelInfo: delete dead comment and duplicate entries, add assertion.
See new tests for more details.
Test Plan: ./validate
Reviewers: austin, dterei, simonmar
Reviewed By: simonmar
Subscribers: thomie, bgamari
Differential Revision: https://phabricator.haskell.org/D974
GHC Trac Issues: #10508
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make tuple constraints be handled by a perfectly ordinary
type class, with the component constraints being the
superclasses:
class (c1, c2) => (c2, c2)
This change was provoked by
#10359 inability to re-use a given tuple
constraint as a whole
#9858 confusion between term tuples
and constraint tuples
but it's generally a very nice simplification. We get rid of
- In Type, the TuplePred constructor of PredTree,
and all the code that dealt with TuplePreds
- In TcEvidence, the constructors EvTupleMk, EvTupleSel
See Note [How tuples work] in TysWiredIn.
Of course, nothing is ever entirely simple. This one
proved quite fiddly.
- I did quite a bit of renaming, which makes this patch
touch a lot of modules. In partiuclar tupleCon -> tupleDataCon.
- I made constraint tuples known-key rather than wired-in.
This is different to boxed/unboxed tuples, but it proved
awkward to have all the superclass selectors wired-in.
Easier just to use the standard mechanims.
- While I was fiddling with known-key names, I split the TH Name
definitions out of DsMeta into a new module THNames. That meant
that the known-key names can all be gathered in PrelInfo, without
causing module loops.
- I found that the parser was parsing an import item like
T( .. )
as a *data constructor* T, and then using setRdrNameSpace to
fix it. Stupid! So I changed the parser to parse a *type
constructor* T, which means less use of setRdrNameSpace.
I also improved setRdrNameSpace to behave better on Exact Names.
Largely on priciple; I don't think it matters a lot.
- When compiling a data type declaration for a wired-in thing like
tuples (,), or lists, we don't really need to look at the
declaration. We have the wired-in thing! And not doing so avoids
having to line up the uniques for data constructor workers etc.
See Note [Declarations for wired-in things]
- I found that FunDeps.oclose wasn't taking superclasses into
account; easily fixed.
- Some error message refactoring for invalid constraints in TcValidity
- Haddock needs to absorb the change too; so there is a submodule update
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts multiple commits from Simon:
- 04a484eafc9eb9f8774b4bdd41a5dc6c9f640daf Test Trac #10359
- a9ccd37add8315e061c02e5bf26c08f05fad9ac9 Test Trac #10403
- c0aae6f699cbd222d826d0b8d78d6cb3f682079e Test Trac #10248
- eb6ca851f553262efe0824b8dcbe64952de4963d Make the "matchable-given" check happen first
- ca173aa30467a0b1023682d573fcd94244d85c50 Add a case to checkValidTyCon
- 51cbad15f86fca1d1b0e777199eb1079a1b64d74 Update haddock submodule
- 6e1174da5b8e0b296f5bfc8b39904300d04eb5b7 Separate transCloVarSet from fixVarSet
- a8493e03b89f3b3bfcdb6005795de050501f5c29 Fix imports in HscMain (stage2)
- a154944bf07b2e13175519bafebd5a03926bf105 Two wibbles to fix the build
- 5910a1bc8142b4e56a19abea104263d7bb5c5d3f Change in capitalisation of error msg
- 130e93aab220bdf14d08028771f83df210da340b Refactor tuple constraints
- 8da785d59f5989b9a9df06386d5bd13f65435bc0 Delete commented-out line
These break the build by causing Haddock to fail mysteriously when
trying to examine GHC.Prim it seems.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make tuple constraints be handled by a perfectly ordinary
type class, with the component constraints being the
superclasses:
class (c1, c2) => (c2, c2)
This change was provoked by
#10359 inability to re-use a given tuple
constraint as a whole
#9858 confusion between term tuples
and constraint tuples
but it's generally a very nice simplification. We get rid of
- In Type, the TuplePred constructor of PredTree,
and all the code that dealt with TuplePreds
- In TcEvidence, the constructors EvTupleMk, EvTupleSel
See Note [How tuples work] in TysWiredIn.
Of course, nothing is ever entirely simple. This one
proved quite fiddly.
- I did quite a bit of renaming, which makes this patch
touch a lot of modules. In partiuclar tupleCon -> tupleDataCon.
- I made constraint tuples known-key rather than wired-in.
This is different to boxed/unboxed tuples, but it proved
awkward to have all the superclass selectors wired-in.
Easier just to use the standard mechanims.
- While I was fiddling with known-key names, I split the TH Name
definitions out of DsMeta into a new module THNames. That meant
that the known-key names can all be gathered in PrelInfo, without
causing module loops.
- I found that the parser was parsing an import item like
T( .. )
as a *data constructor* T, and then using setRdrNameSpace to
fix it. Stupid! So I changed the parser to parse a *type
constructor* T, which means less use of setRdrNameSpace.
I also improved setRdrNameSpace to behave better on Exact Names.
Largely on priciple; I don't think it matters a lot.
- When compiling a data type declaration for a wired-in thing like
tuples (,), or lists, we don't really need to look at the
declaration. We have the wired-in thing! And not doing so avoids
having to line up the uniques for data constructor workers etc.
See Note [Declarations for wired-in things]
- I found that FunDeps.oclose wasn't taking superclasses into
account; easily fixed.
- Some error message refactoring for invalid constraints in TcValidity
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This motivation is to declare class IP much earlier (in ghc-prim),
so that implicit parameters (which depend on IP) is available
to library code, notably the 'error' function.
* Move class IP from base:GHC.IP
to ghc-prim:GHC.Classes
* Delete module GHC.IP from base
* Move types Symbol and Nat
from base:GHC.TypeLits
to ghc-prim:GHC.Types
There was a name clash in GHC.RTS.Flags, where I renamed
the local type Nat to RtsNat.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This completes what c774b28f76ee4c220f7c1c9fd81585e0e3af0e8a (#9281)
started. `integer-gmp-1.0` was added as an additional
`libraries/integer-gmp2` folder while retaining the ability to configure
GHC w/ the old `integer-gmp-0.5` to have a way back, and or the ability
to easily switch between old/new `integer-gmp` for benchmark/debugging
purposes.
This commit removes the old `libraries/integer-gmp` folder and moves
`libraries/integer-gmp2` into its place, while removing any mentions of
"gmp2" as well as the to support two different `integer-gmp` packages in
GHC's source-tree.
Reviewed By: austin
Differential Revision: https://phabricator.haskell.org/D769
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This implements the new `Typeable` solver: when GHC sees `Typeable` constraints
it solves them on the spot.
The current implementation creates `TyCon` representations on the spot.
Pro: No overhead at all in code that does not use `Typeable`
Cons: Code that uses `Typeable` may create multipe `TyCon` represntations.
We have discussed an implementation where representations of `TyCons` are
computed once, in the module, where a datatype is declared. This would
lead to more code being generated: for a promotable datatype we need to
generate `2 + number_of_data_cons` type-constructro representations,
and we have to do that for all programs, even ones that do not intend to
use typeable.
I added code to emit warning whenevar `deriving Typeable` is encountered---
the idea being that this is not needed anymore, and shold be fixed.
Also, we allow `instance Typeable T` in .hs-boot files, but they result
in a warning, and are ignored. This last one was to avoid breaking exisitng
code, and should become an error, eventually.
Test Plan:
1. GHC can compile itself.
2. I compiled a number of large libraries, including `lens`.
- I had to make some small changes:
`unordered-containers` uses internals of `TypeReps`, so I had to do a 1 line fix
- `lens` needed one instance changed, due to a poly-kinded `Typeble` instance
3. I also run some code that uses `syb` to traverse a largish datastrucutre.
I didn't notice any signifiant performance difference between the 7.8.3 version,
and this implementation.
Reviewers: simonpj, simonmar, austin, hvr
Reviewed By: austin, hvr
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D652
GHC Trac Issues: #9858
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: deriving/should_run/T10104
Reviewers: austin, jstolarek
Reviewed By: austin, jstolarek
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D672
GHC Trac Issues: #10104
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Added packageName to GHC.Generics.Datatype class definition
Reviewers: hvr, dreixel, austin
Reviewed By: dreixel, austin
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D631
GHC Trac Issues: #10030
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
IPs with this type will always be solved for the current source
location. If another IP of the same type is in scope, the two locations will be
appended, creating a call-stack. The Location type is kept abstract so users
cannot create them, but a Location can be turned into a list of SrcLocs, which
correspond to individual locations in a program. Each SrcLoc contains a
package/module/file name and start/end lines and columns.
The only thing missing from the SrcLoc in my opinion is the name of the
top-level definition it inhabits. I suspect that would also be useful, but it's
not clear to me how to extract the current top-level binder from within the
constraint solver. (Surely I'm just missing something here?)
I made the (perhaps controversial) decision to have GHC completely ignore
the names of Location IPs, meaning that in the following code:
bar :: (?myloc :: Location) => String
bar = foo
foo :: (?loc :: Location) => String
foo = show ?loc
if I call `bar`, the resulting call-stack will include locations for
1. the use of `?loc` inside `foo`,
2. `foo`s call-site inside `bar`, and
3. `bar`s call-site, wherever that may be.
This makes Location IPs very special indeed, and I'm happy to change it if the
dissonance is too great.
I've also left out any changes to base to make use of Location IPs, since there
were some concerns about a snowball effect. I think it would be reasonable to
mark this as an experimental feature for now (it is!), and defer using it in
base until we have more experience with it. It is, after all, quite easy to
define your own version of `error`, `undefined`, etc. that use Location IPs.
Test Plan: validate, new test-case is testsuite/tests/typecheck/should_run/IPLocation.hs
Reviewers: austin, hvr, simonpj
Reviewed By: simonpj
Subscribers: simonmar, rodlogic, carter, thomie
Differential Revision: https://phabricator.haskell.org/D578
GHC Trac Issues: #9049
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
As proposed in [1], this extension introduces a new syntactic form
`static e`, where `e :: a` can be any closed expression. The static form
produces a value of type `StaticPtr a`, which works as a reference that
programs can "dereference" to get the value of `e` back. References are
like `Ptr`s, except that they are stable across invocations of a
program.
The relevant wiki pages are [2, 3], which describe the motivation/ideas
and implementation plan respectively.
[1] Jeff Epstein, Andrew P. Black, and Simon Peyton-Jones. Towards
Haskell in the cloud. SIGPLAN Not., 46(12):118–129, September 2011. ISSN
0362-1340.
[2] https://ghc.haskell.org/trac/ghc/wiki/StaticPointers
[3] https://ghc.haskell.org/trac/ghc/wiki/StaticPointers/ImplementationPlan
Authored-by: Facundo Domínguez <facundo.dominguez@tweag.io>
Authored-by: Mathieu Boespflug <m@tweag.io>
Authored-by: Alexander Vershilov <alexander.vershilov@tweag.io>
Test Plan: `./validate`
Reviewers: hvr, simonmar, simonpj, austin
Reviewed By: simonpj, austin
Subscribers: qnikst, bgamari, mboes, carter, thomie, goldfire
Differential Revision: https://phabricator.haskell.org/D550
GHC Trac Issues: #7015
|
|
|
Signed-off-by: Austin Seipp <austin@well-typed.com>
|
