summaryrefslogtreecommitdiff
path: root/testsuite/tests/roles/should_compile/Roles3.stderr
Commit message (Collapse)AuthorAgeFilesLines
* Address #11471 by putting RuntimeRep in kinds.wip/runtime-repRichard Eisenberg2016-02-241-4/+2
| | | | | | | | | | | | | | | | | | | | | See Note [TYPE] in TysPrim. There are still some outstanding pieces in #11471 though, so this doesn't actually nail the bug. This commit also contains a few performance improvements: * Short-cut equality checking of nullary type syns * Compare types before kinds in eqType * INLINE coreViewOneStarKind * Store tycon binders separately from kinds. This resulted in a ~10% performance improvement in compiling the Cabal package. No change in functionality other than performance. (This affects the interface file format, though.) This commit updates the haddock submodule.
* Refactoring on IdInfo and system derived namesSimon Peyton Jones2016-01-181-17/+45
| | | | | | | | | | | | | | | | | | | | Some modest refactoring, triggered in part by Trac #11051 * Kill off PatSynId, ReflectionId in IdDetails They were barely used, and only for pretty-printing * Add helper function Id.mkExportedVanillaId, and use it * Polish up OccName.isDerivedOccName, as a predicate for definitions generated internally by GHC, which we might not want to show to the user. * Kill off unused OccName.mkDerivedTyConOcc * Shorten the derived OccNames for newtype and data instance axioms * A bit of related refactoring around newFamInstAxiomName
* Narrow scope of special-case for unqualified printing of names in core librariesBen Gamari2015-12-151-9/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 547c597112954353cef7157cb0a389bc4f6303eb modifies the pretty-printer to render names from a set of core packages (`base`, `ghc-prim`, `template-haskell`) as unqualified. The idea here was that many of these names typically are not in scope but are well-known by the user and therefore qualification merely introduces noise. This, however, is a very large hammer and potentially breaks any consumer who relies on parsing GHC output (hence #11208). This commit partially reverts this change, now only printing `Constraint` (which appears quite often in errors) as unqualified. Fixes #11208. Updates tests in `array` submodule. Test Plan: validate Reviewers: hvr, thomie, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1619 GHC Trac Issues: #11208
* Add kind equalities to GHC.Richard Eisenberg2015-12-111-26/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Fix inconsistent pretty-printing of type familiesMichał Sośnicki2015-11-181-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | After the changes, the three functions used to print type families were identical, so they are refactored into one. Original RHSs of data instance declarations are recreated and printed in user error messages. RHSs containing representation TyCons are printed in the Coercion Axioms section in a typechecker dump. Add vbar to the list of SDocs exported by Outputable. Replace all text "|" docs with it. Fixes #10839 Reviewers: goldfire, jstolarek, austin, bgamari Reviewed By: jstolarek Subscribers: jstolarek, thomie Differential Revision: https://phabricator.haskell.org/D1441 GHC Trac Issues: #10839
* Bump ghc-prim version to 0.5.0.0 (closes #11043)Herbert Valerio Riedel2015-11-011-1/+1
| | | | | | | | | | | This also needs to update the primitive/vector submodules in order to relax upper bounds on ghc-prim. Like in f8ba4b55cc3a061458f5cfabf17de96128defbbb, a mass-rewrite in testsuite/ via sed -i s,ghc-prim-0.4.0.0,ghc-prim-0.5.0.0,g $(git grep -Fl 'ghc-prim-0.4.0.0') was performed.
* Bump `base` version to 4.9.0.0 (closes #11026)Herbert Valerio Riedel2015-11-011-1/+1
| | | | | | | | | | | This also relaxes a few upper bounds on base in the ghc.git repo; This required a mass-rewrite in testsuite/ sed -i s,base-4.8.2.0,base-4.9.0.0,g $(git grep -Fl 'base-4.8.2.0') because it turns out the testsuite is still sensitive to package version changes.
* Generate Typeable info at definition sitesBen Gamari2015-10-301-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the second attempt at merging D757. This patch implements the idea floated in Trac #9858, namely that we should generate type-representation information at the data type declaration site, rather than when solving a Typeable constraint. However, this turned out quite a bit harder than I expected. I still think it's the right thing to do, and it's done now, but it was quite a struggle. See particularly * Note [Grand plan for Typeable] in TcTypeable (which is a new module) * Note [The overall promotion story] in DataCon (clarifies existing stuff) The most painful bit was that to generate Typeable instances (ie TyConRepName bindings) for every TyCon is tricky for types in ghc-prim etc: * We need to have enough data types around to *define* a TyCon * Many of these types are wired-in Also, to minimise the code generated for each data type, I wanted to generate pure data, not CAFs with unpackCString# stuff floating about. Performance ~~~~~~~~~~~ Three perf/compiler tests start to allocate quite a bit more. This isn't surprising, because they all allocate zillions of data types, with practically no other code, esp. T1969 * T1969: GHC allocates 19% more * T4801: GHC allocates 13% more * T5321FD: GHC allocates 13% more * T9675: GHC allocates 11% more * T783: GHC allocates 11% more * T5642: GHC allocates 10% more I'm treating this as acceptable. The payoff comes in Typeable-heavy code. Remaining to do ~~~~~~~~~~~~~~~ * I think that "TyCon" and "Module" are over-generic names to use for the runtime type representations used in GHC.Typeable. Better might be "TrTyCon" and "TrModule". But I have not yet done this * Add more info the the "TyCon" e.g. source location where it was defined * Use the new "Module" type to help with Trac Trac #10068 * It would be possible to generate TyConRepName (ie Typeable instances) selectively rather than all the time. We'd need to persist the information in interface files. Lacking a motivating reason I have not done this, but it would not be difficult. Refactoring ~~~~~~~~~~~ As is so often the case, I ended up refactoring more than I intended. In particular * In TyCon, a type *family* (whether type or data) is repesented by a FamilyTyCon * a algebraic data type (including data/newtype instances) is represented by AlgTyCon This wasn't true before; a data family was represented as an AlgTyCon. There are some corresponding changes in IfaceSyn. * Also get rid of the (unhelpfully named) tyConParent. * In TyCon define 'Promoted', isomorphic to Maybe, used when things are optionally promoted; and use it elsewhere in GHC. * Cleanup handling of knownKeyNames * Each TyCon, including promoted TyCons, contains its TyConRepName, if it has one. This is, in effect, the name of its Typeable instance. Updates haddock submodule Test Plan: Let Harbormaster validate Reviewers: austin, hvr, goldfire Subscribers: goldfire, thomie Differential Revision: https://phabricator.haskell.org/D1404 GHC Trac Issues: #9858
* Revert "Generate Typeable info at definition sites"Ben Gamari2015-10-291-25/+0
| | | | | | | | This reverts commit bef2f03e4d56d88a7e9752a7afd6a0a35616da6c. This merge was botched Also reverts haddock submodule.
* Generate Typeable info at definition sitesBen Gamari2015-10-291-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements the idea floated in Trac #9858, namely that we should generate type-representation information at the data type declaration site, rather than when solving a Typeable constraint. However, this turned out quite a bit harder than I expected. I still think it's the right thing to do, and it's done now, but it was quite a struggle. See particularly * Note [Grand plan for Typeable] in TcTypeable (which is a new module) * Note [The overall promotion story] in DataCon (clarifies existing stuff) The most painful bit was that to generate Typeable instances (ie TyConRepName bindings) for every TyCon is tricky for types in ghc-prim etc: * We need to have enough data types around to *define* a TyCon * Many of these types are wired-in Also, to minimise the code generated for each data type, I wanted to generate pure data, not CAFs with unpackCString# stuff floating about. Performance ~~~~~~~~~~~ Three perf/compiler tests start to allocate quite a bit more. This isn't surprising, because they all allocate zillions of data types, with practically no other code, esp. T1969 * T3294: GHC allocates 110% more (filed #11030 to track this) * T1969: GHC allocates 30% more * T4801: GHC allocates 14% more * T5321FD: GHC allocates 13% more * T783: GHC allocates 12% more * T9675: GHC allocates 12% more * T5642: GHC allocates 10% more * T9961: GHC allocates 6% more * T9203: Program allocates 54% less I'm treating this as acceptable. The payoff comes in Typeable-heavy code. Remaining to do ~~~~~~~~~~~~~~~ * I think that "TyCon" and "Module" are over-generic names to use for the runtime type representations used in GHC.Typeable. Better might be "TrTyCon" and "TrModule". But I have not yet done this * Add more info the the "TyCon" e.g. source location where it was defined * Use the new "Module" type to help with Trac Trac #10068 * It would be possible to generate TyConRepName (ie Typeable instances) selectively rather than all the time. We'd need to persist the information in interface files. Lacking a motivating reason I have not done this, but it would not be difficult. Refactoring ~~~~~~~~~~~ As is so often the case, I ended up refactoring more than I intended. In particular * In TyCon, a type *family* (whether type or data) is repesented by a FamilyTyCon * a algebraic data type (including data/newtype instances) is represented by AlgTyCon This wasn't true before; a data family was represented as an AlgTyCon. There are some corresponding changes in IfaceSyn. * Also get rid of the (unhelpfully named) tyConParent. * In TyCon define 'Promoted', isomorphic to Maybe, used when things are optionally promoted; and use it elsewhere in GHC. * Cleanup handling of knownKeyNames * Each TyCon, including promoted TyCons, contains its TyConRepName, if it has one. This is, in effect, the name of its Typeable instance. Requires update of the haddock submodule. Differential Revision: https://phabricator.haskell.org/D757
* Show minimal complete definitions in ghci (#10847)Moritz Kiefer2015-09-171-0/+4
| | | | | | | | | | | Show the minimal complete definition on :info in ghci. They are shown like MINIMAL pragmas in code. If the minimal complete definition is empty or only a specific method from a class is requested, nothing is shown. Reviewed By: simonpj, austin, thomie Differential Revision: https://phabricator.haskell.org/D1241
* Bump base version to 4.8.2.0Herbert Valerio Riedel2015-04-251-1/+1
| | | | | | This is needed because GHC 7.10.2 requires a minor version bump to base-4.8.1.0 Several test outputs needed base-4.8.1.0 replaced by base-4.8.2.0
* Minor bump `base` version to 4.8.1.0Herbert Valerio Riedel2015-03-231-1/+1
| | | | | We've accumulated enough to justify a minor version bump to 4.8.1.0, but not enough to justify a major version bump yet as far as I can see.
* Bump ghc-prim to 0.4.0.0Herbert Valerio Riedel2015-03-201-2/+2
| | | | | | | | | | | | This major version bump was made necessary by f44333eae7bc7dc7b6003b75874a02445f6b633b which changed the type signatures of prefetch primops, as well as other changes such as 051d694fc978ad28ac3043d296cafddd3c2a7050 turning `Any` into an abstract closed type family. Reviewed By: ekmett Differential Revision: https://phabricator.haskell.org/D743
* Use correct precedence when printing contexts with class operatorsSimon Peyton Jones2014-10-071-1/+1
| | | | Fixes Trac #9658
* Bump `base` version to 4.8.0.0 for realHerbert Valerio Riedel2014-09-091-1/+1
| | | | | | | | | | | | | | | | This commit updates several submodules in order to bump the upper bounds on `base` of most boot packages Moreover, this updates some of the test-suite cases which have version numbers hardcoded within. However, I'm not sure if this commit didn't introduce the following two test-failures ghc-api T8628 [bad stdout] (normal) ghc-api T8639_api [bad stdout] (normal) This needs investigation
* Do not zero out version number when processing wired-in packages.Edward Z. Yang2014-08-221-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Previously, GHC would look for instances of wired-in packages in the in-memory package database and null out the version number. This was necessary when the sourcePackageId was used to determine the linker symbols; however, we now use a package key, so only that needs to be updated. Long-term, we can remove this hack by ensuring that Cabal actually records the proper package key in the database. This will also fix an unrelated hack elsewhere. Keeping version numbers means that wired in packages get rendered differently when output by GHC. This is the source of all the test-case output changes. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: hvr, austin Subscribers: simonmar, ezyang, carter Differential Revision: https://phabricator.haskell.org/D170
* Do pretty-printing of TyThings via IfaceDecl (Trac #7730)Simon Peyton Jones2014-06-031-22/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | All the initial work on this was done fy 'archblob' (fcsernik@gmail.com); thank you! I reviewed the patch, started some tidying, up and then ended up in a huge swamp of changes, not all of which I can remember now. But: * To suppress kind arguments when we have -fno-print-explicit-kinds, - IfaceTyConApp argument types are in a tagged list IfaceTcArgs * To allow overloaded types to be printed with =>, add IfaceDFunTy to IfaceType. * When printing data/type family instances for the user, I've made them print out an informative RHS, which is a new feature. Thus ghci> info T data family T a data instance T Int = T1 Int Int data instance T Bool = T2 * In implementation terms, pprIfaceDecl has just one "context" argument, of type IfaceSyn.ShowSub, which says - How to print the binders of the decl see note [Printing IfaceDecl binders] in IfaceSyn - Which sub-comoponents (eg constructors) to print * Moved FastStringEnv from RnEnv to OccName It all took a ridiculously long time to do. But it's done!
* Wibbles to output regarding role annotations.Richard Eisenberg2013-10-231-3/+3
|
* Error messsage wibblificationSimon Peyton Jones2013-10-041-14/+14
|
* Update to tests due to change in syntax for role annotations.Richard Eisenberg2013-09-171-0/+39