summaryrefslogtreecommitdiff
path: root/testsuite/tests/roles
Commit message (Collapse)AuthorAgeFilesLines
...
* Fix #15039 by pretty-printing equalities more systematicallyRyan Scott2018-05-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | GHC previously had a handful of special cases for pretty-printing equalities in a more user-friendly manner, but they were far from comprehensive (see #15039 for an example of where this fell apart). This patch makes the pretty-printing of equalities much more systematic. I've adopted the approach laid out in https://ghc.haskell.org/trac/ghc/ticket/15039#comment:4, and updated `Note [Equality predicates in IfaceType]` accordingly. We are now more careful to respect the properties of the `-fprint-explicit-kinds` and `-fprint-equality-relations` flags, which led to some improvements in error message outputs. Along the way, I also tweaked the error-reporting machinery not to print out the type of a typed hole when the type is an unlifted equality, since it's kind (`TYPE ('TupleRep '[])`) was more confusing than anything. Test Plan: make test TEST="T15039a T15039b T15039c T15039d" Reviewers: simonpj, goldfire, bgamari Reviewed By: simonpj Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15039 Differential Revision: https://phabricator.haskell.org/D4696
* Add 'addWordC#' PrimOpSebastian Graf2018-05-056-6/+6
| | | | | | | | | | | | | | | | | | | This is mostly for congruence with 'subWordC#' and '{add,sub}IntC#'. I found 'plusWord2#' while implementing this, which both lacks documentation and has a slightly different specification than 'addWordC#', which means the generic implementation is unnecessarily complex. While I was at it, I also added lacking meta-information on PrimOps and refactored 'subWordC#'s generic implementation to be branchless. Reviewers: bgamari, simonmar, jrtc27, dfeuer Reviewed By: bgamari, dfeuer Subscribers: dfeuer, thomie, carter Differential Revision: https://phabricator.haskell.org/D4592
* Bump base to version 4.12.0.0Ryan Scott2018-04-196-6/+6
| | | | | | | | | | | | | | | | Summary: Bumps several submodules. Test Plan: ./validate Reviewers: hvr, bgamari Reviewed By: bgamari Subscribers: thomie, carter GHC Trac Issues: #15018 Differential Revision: https://phabricator.haskell.org/D4609
* Bump version numbers: base-4.11.1.0, integer-gmp-1.0.2.0Ryan Scott2018-04-136-12/+12
| | | | | | | | | | | | | | | | | | | | | This takes care of bumping the `base` and `integer-gmp` minor version numbers in anticipation of a GHC 8.4.2 release. While I was in town, I also filled in a `@since TODO` Haddock annotation for `powModSecInteger` in `integer-gmp` with `1.0.2.0`, and updated the changelog accordingly. Test Plan: ./validate Reviewers: hvr, goldfire, bgamari Reviewed By: bgamari Subscribers: thomie, carter GHC Trac Issues: #15025 Differential Revision: https://phabricator.haskell.org/D4586
* Get evaluated-ness right in the back endSimon Peyton Jones2018-01-031-26/+26
| | | | | | | | | | | | | | | | See Trac #14626, comment:4. We want to maintain evaluted-ness info on Ids into the code generateor for two reasons (see Note [Preserve evaluated-ness in CorePrep] in CorePrep) - DataToTag magic - Potentially using it in the codegen (this is Gabor's current work) But it was all being done very inconsistently, and actually outright wrong -- the DataToTag magic hasn't been working for years. This patch tidies it all up, with Notes to match.
* Bump ghc-prim to 0.5.2.0 and update changelogHerbert Valerio Riedel2017-10-176-6/+6
| | | | | | | This is prompted by the addition of `compareByteArrays#` in e3ba26f8b49700b41ff4672f3f7f6a4e453acdcc NOTE: We may switch to synchronise `ghc-prim` with GHC's version at some point
* Bump base to 4.11.0.0Ben Gamari2017-09-216-6/+6
| | | | | | | | | | Bumps numerous submodules. Reviewers: austin, hvr Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3974
* Allow CSE'ing of work-wrapped bindings (#14186)Joachim Breitner2017-09-126-75/+81
| | | | | | | | the worker/wrapper creates an artificial INLINE pragma, which caused CSE to not do its work. We now recognize such artificial pragmas by using `NoUserInline` instead of `Inline` as the `InlineSpec`. Differential Revision: https://phabricator.haskell.org/D3939
* Add test for #14101Ryan Scott2017-08-122-0/+11
| | | | | I forgot to do this in 0bb1e84034a12d7f700b48fca6710c01bd08f397.
* Preserve CoVar uniques during pretty printingRichard Eisenberg2017-07-271-1/+1
| | | | Previously, we did this for Types, but not for Coercions.
* ghc-prim: Bump versionBen Gamari2017-07-236-6/+6
| | | | (cherry picked from commit 8c5405f63c2de0c445ec171aab63c35786544b9e)
* Some tidying up of type pretty-printingSimon Peyton Jones2017-05-262-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | Triggered by the changes in #13677, I ended up doing a bit of refactoring in type pretty-printing. * We were using TyOpPrec and FunPrec rather inconsitently, so I made it consisent. * That exposed the fact that we were a bit undecided about whether to print a + b -> c + d vs (a+b) -> (c+d) and similarly a ~ [b] => blah vs (a ~ [b]) => blah I decided to make TyOpPrec and FunPrec compare equal (in BasicTypes), so (->) is treated as equal precedence with other type operators, so you get the unambiguous forms above, even though they have more parens. We could readily reverse this decision. See Note [Type operator precedence] in BasicTypes * I fixed a bug in pretty-printing of HsType where some parens were omitted by mistake.
* Clean up coreView/tcView.Ben Gamari2017-03-314-9/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In Core, Constraint should be considered fully equal to TYPE LiftedRep, in all ways. Accordingly, coreView should unwrap Constraint to become TYPE LiftedRep. Of course, this would be a disaster in the type checker. So, where previously we used coreView in both the type checker and in Core, we now have coreView and tcView, which differ only in their treatment of Constraint. Historical note: once upon a past, we had tcView distinct from coreView. Back then, it was because newtypes were unwrapped in Core but not in the type checker. The distinction is back, but for a different reason than before. This had a few knock-on effects: * The Typeable solver must explicitly handle Constraint to ensure that we produce the correct evidence. * TypeMap now respects the Constraint/Type distinction Finished by: bgamari Test Plan: ./validate Reviewers: simonpj, austin, bgamari Reviewed By: simonpj Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3316
* Produce KindReps for common kinds in GHC.TypesBen Gamari2017-03-037-66/+45
| | | | | | | | | | | | | | | | | | | | | | | | | Unfortunately this comes with a fair bit of implementation cost. Perhaps some refactoring would help, but in the interest of getting 8.2 out the door I'm pushing as-is. While this doesn't have nearly the effect on compiler allocations that D3166 has, it's still nothing to sneeze at. nofib shows, ``` ------------------------------------------------------------------------ Program master D3166 D3219 ------------------------------------------------------------------------ -1 s.d. ----- -3.555% -4.081% +1 s.d. ----- +1.937% +1.593% Average ----- -0.847% -1.285% ``` Test Plan: Validate Reviewers: austin Subscribers: thomie, simonmar Differential Revision: https://phabricator.haskell.org/D3219
* TcTypeable: Try to reuse KindRepsBen Gamari2017-03-037-251/+136
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Here we rework the TcTypeable implementation to reuse KindRep bindings when possible. This is an attempt at minimizing the impact of Typeable binding generation by reducing the number of bindings that we produce. It turns out that this produces some pretty reasonable compiler allocations improvements. It seems to erase most of the increases initially introduced by TTypeable in the testsuite. Moreover, nofib shows, ``` -1 s.d. ----- -3.555% +1 s.d. ----- +1.937% Average ----- -0.847% ``` Here are a few of the high-scorers (ignore last column, which is for D3219), ``` veritas Types 88800920 -18.945% -21.480% veritas Tactics 540766744 -27.256% -27.338% sched Main 567013384 -4.947% -5.358% listcompr Main 532300000 -4.273% -4.572% listcopy Main 537785392 -4.382% -4.635% anna BaseDefs 1984225032 -10.639% -10.832% ``` as expected, these tend to be modules with either very many or very large types. Test Plan: Validate Reviewers: austin, dfeuer Subscribers: simonmar, dfeuer, thomie Differential Revision: https://phabricator.haskell.org/D3166
* Typeable: Rename KindRep bindings to $krep...Ben Gamari2017-03-027-138/+138
|
* Treat all TyCon with hole names as skolem abstract.Edward Z. Yang2017-02-262-2/+2
| | | | | | | | | | | | | | | Summary: Fixes #13335. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: goldfire, austin, simonpj, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3211
* Type-indexed TypeableBen Gamari2017-02-187-119/+462
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This at long last realizes the ideas for type-indexed Typeable discussed in A Reflection on Types (#11011). The general sketch of the project is described on the Wiki (Typeable/BenGamari). The general idea is that we are adding a type index to `TypeRep`, data TypeRep (a :: k) This index allows the typechecker to reason about the type represented by the `TypeRep`. This index representation mechanism is exposed as `Type.Reflection`, which also provides a number of patterns for inspecting `TypeRep`s, ```lang=haskell pattern TRFun :: forall k (fun :: k). () => forall (r1 :: RuntimeRep) (r2 :: RuntimeRep) (arg :: TYPE r1) (res :: TYPE r2). (k ~ Type, fun ~~ (arg -> res)) => TypeRep arg -> TypeRep res -> TypeRep fun pattern TRApp :: forall k2 (t :: k2). () => forall k1 (a :: k1 -> k2) (b :: k1). (t ~ a b) => TypeRep a -> TypeRep b -> TypeRep t -- | Pattern match on a type constructor. pattern TRCon :: forall k (a :: k). TyCon -> TypeRep a -- | Pattern match on a type constructor including its instantiated kind -- variables. pattern TRCon' :: forall k (a :: k). TyCon -> [SomeTypeRep] -> TypeRep a ``` In addition, we give the user access to the kind of a `TypeRep` (#10343), typeRepKind :: TypeRep (a :: k) -> TypeRep k Moreover, all of this plays nicely with 8.2's levity polymorphism, including the newly levity polymorphic (->) type constructor. Library changes --------------- The primary change here is the introduction of a Type.Reflection module to base. This module provides access to the new type-indexed TypeRep introduced in this patch. We also continue to provide the unindexed Data.Typeable interface, which is simply a type synonym for the existentially quantified SomeTypeRep, data SomeTypeRep where SomeTypeRep :: TypeRep a -> SomeTypeRep Naturally, this change also touched Data.Dynamic, which can now export the Dynamic data constructor. Moreover, I removed a blanket reexport of Data.Typeable from Data.Dynamic (which itself doesn't even import Data.Typeable now). We also add a kind heterogeneous type equality type, (:~~:), to Data.Type.Equality. Implementation -------------- The implementation strategy is described in Note [Grand plan for Typeable] in TcTypeable. None of it was difficult, but it did exercise a number of parts of the new levity polymorphism story which had not yet been exercised, which took some sorting out. The rough idea is that we augment the TyCon produced for each type constructor with information about the constructor's kind (which we call a KindRep). This allows us to reconstruct the monomorphic result kind of an particular instantiation of a type constructor given its kind arguments. Unfortunately all of this takes a fair amount of work to generate and send through the compilation pipeline. In particular, the KindReps can unfortunately get quite large. Moreover, the simplifier will float out various pieces of them, resulting in numerous top-level bindings. Consequently we mark the KindRep bindings as noinline, ensuring that the float-outs don't make it into the interface file. This is important since there is generally little benefit to inlining KindReps and they would otherwise strongly affect compiler performance. Performance ----------- Initially I was hoping to also clear up the remaining holes in Typeable's coverage by adding support for both unboxed tuples (#12409) and unboxed sums (#13276). While the former was fairly straightforward, the latter ended up being quite difficult: while the implementation can support them easily, enabling this support causes thousands of Typeable bindings to be emitted to the GHC.Types as each arity-N sum tycon brings with it N promoted datacons, each of which has a KindRep whose size which itself scales with N. Doing this was simply too expensive to be practical; consequently I've disabled support for the time being. Even after disabling sums this change regresses compiler performance far more than I would like. In particular there are several testcases in the testsuite which consist mostly of types which regress by over 30% in compiler allocations. These include (considering the "bytes allocated" metric), * T1969: +10% * T10858: +23% * T3294: +19% * T5631: +41% * T6048: +23% * T9675: +20% * T9872a: +5.2% * T9872d: +12% * T9233: +10% * T10370: +34% * T12425: +30% * T12234: +16% * 13035: +17% * T4029: +6.1% I've spent quite some time chasing down the source of this regression and while I was able to make som improvements, I think this approach of generating Typeable bindings at time of type definition is doomed to give us unnecessarily large compile-time overhead. In the future I think we should consider moving some of all of the Typeable binding generation logic back to the solver (where it was prior to 91c6b1f54aea658b0056caec45655475897f1972). I've opened #13261 documenting this proposal.
* Say 'data' explicitly in IfAbstractTyCon output.Edward Z. Yang2017-02-172-2/+2
| | | | Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
* Join pointsLuke Maurer2017-02-011-20/+21
| | | | | | | | | | | | | | | | | | | This major patch implements Join Points, as described in https://ghc.haskell.org/trac/ghc/wiki/SequentCore. You have to read that page, and especially the paper it links to, to understand what's going on; but it is very cool. It's Luke Maurer's work, but done in close collaboration with Simon PJ. This Phab is a squash-merge of wip/join-points branch of http://github.com/lukemaurer/ghc. There are many, many interdependent changes. Reviewers: goldfire, mpickering, bgamari, simonmar, dfeuer, austin Subscribers: simonpj, dfeuer, mpickering, Mikolaj, thomie Differential Revision: https://phabricator.haskell.org/D2853
* Remove clean_cmd and extra_clean usage from .T filesThomas Miedema2017-01-222-6/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | The `clean_cmd` and `extra_clean` setup functions don't do anything. Remove them from .T files. Created using https://github.com/thomie/refactor-ghc-testsuite. This diff is a test for the .T-file parser/processor/pretty-printer in that repository. find . -name '*.T' -exec ~/refactor-ghc-testsuite/Main "{}" \; Tests containing inline comments or multiline strings are not modified. Preparation for #12223. Test Plan: Harbormaster Reviewers: austin, hvr, simonmar, mpickering, bgamari Reviewed By: mpickering Subscribers: mpickering Differential Revision: https://phabricator.haskell.org/D3000 GHC Trac Issues: #12223
* Allow top-level string literals in Core (#8472)Takano Akio2017-01-201-18/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commits relaxes the invariants of the Core syntax so that a top-level variable can be bound to a primitive string literal of type Addr#. This commit: * Relaxes the invatiants of the Core, and allows top-level bindings whose type is Addr# as long as their RHS is either a primitive string literal or another variable. * Allows the simplifier and the full-laziness transformer to float out primitive string literals to the top leve. * Introduces the new StgGenTopBinding type to accomodate top-level Addr# bindings. * Introduces a new type of labels in the object code, with the suffix "_bytes", for exported top-level Addr# bindings. * Makes some built-in rules more robust. This was necessary to keep them functional after the above changes. This is a continuation of D2554. Rebasing notes: This had two slightly suspicious performance regressions: * T12425: bytes allocated regressed by roughly 5% * T4029: bytes allocated regressed by a bit over 1% * T13035: bytes allocated regressed by a bit over 5% These deserve additional investigation. Rebased by: bgamari. Test Plan: ./validate --slow Reviewers: goldfire, trofi, simonmar, simonpj, austin, hvr, bgamari Reviewed By: trofi, simonpj, bgamari Subscribers: trofi, simonpj, gridaphobe, thomie Differential Revision: https://phabricator.haskell.org/D2605 GHC Trac Issues: #8472
* base: Bump version to 4.10.0.0Ben Gamari2016-12-156-6/+6
| | | | Updates a number of submodules.
* Add HsSyn prettyprinter testsAlan Zimmerman2016-12-071-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Add prettyprinter tests, which take a file, parse it, pretty print it, re-parse the pretty printed version and then compare the original and new ASTs (ignoring locations) Updates haddock submodule to match the AST changes. There are three issues outstanding 1. Extra parens around a context are not reproduced. This will require an AST change and will be done in a separate patch. 2. Currently if an `HsTickPragma` is found, this is not pretty-printed, to prevent noise in the output. I am not sure what the desired behaviour in this case is, so have left it as before. Test Ppr047 is marked as expected fail for this. 3. Apart from in a context, the ParsedSource AST keeps all the parens from the original source. Something is happening in the renamer to remove the parens around visible type application, causing T12530 to fail, as the dumped splice decl is after the renamer. This needs to be fixed by keeping the parens, but I do not know where they are being removed. I have amended the test to pass, by removing the parens in the expected output. Test Plan: ./validate Reviewers: goldfire, mpickering, simonpj, bgamari, austin Reviewed By: simonpj, bgamari Subscribers: simonpj, goldfire, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D2752 GHC Trac Issues: #3384
* Kill Type pretty-printerBen Gamari2016-11-131-4/+2
| | | | | | | | | | | | | | | | | | | | | | Here we consolidate the pretty-printing logic for types in IfaceType. We need IfaceType regardless and the printer for Type can be implemented in terms of that for IfaceType. See #11660. Note that this is very much a work-in-progress. Namely I still have yet to ponder how to ease the hs-boot file situation, still need to rip out more dead code, need to move some of the special cases for, e.g., `*` to the IfaceType printer, and need to get it to validate. That being said, it comes close to validating as-is. Test Plan: Validate Reviewers: goldfire, austin Subscribers: goldfire, thomie, simonpj Differential Revision: https://phabricator.haskell.org/D2528 GHC Trac Issues: #11660
* A collection of type-inference refactorings.Simon Peyton Jones2016-10-211-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch does a raft of useful tidy-ups in the type checker. I've been meaning to do this for some time, and finally made time to do it en route to ICFP. 1. Modify TcType.ExpType to make a distinct data type, InferResult for the Infer case, and consequential refactoring. 2. Define a new function TcUnify.fillInferResult, to fill in an InferResult. It uses TcMType.promoteTcType to promote the type to the level of the InferResult. See TcMType Note [Promoting a type] This refactoring is in preparation for an improvement to typechecking pattern bindings, coming next. I flirted with an elaborate scheme to give better higher rank inference, but it was just too complicated. See TcMType Note [Promotion and higher rank types] 3. Add to InferResult a new field ir_inst :: Bool to say whether or not the type used to fill in the InferResult should be deeply instantiated. See TcUnify Note [Deep instantiation of InferResult]. 4. Add a TcLevel to SkolemTvs. This will be useful generally - it's a fast way to see if the type variable escapes when floating (not used yet) - it provides a good consistency check when updating a unification variable (TcMType.writeMetaTyVarRef, the level_check_ok check) I originally had another reason (related to the flirting in (2), but I left it in because it seems like a step in the right direction. 5. Reduce and simplify the plethora of uExpType, tcSubType and related functions in TcUnify. It was such an opaque mess and it's still not great, but it's better. 6. Simplify the uo_expected field of TypeEqOrigin. Richard had generatlised it to a ExpType, but it was almost always a Check type. Now it's back to being a plain TcType which is much, much easier. 7. Improve error messages by refraining from skolemisation when it's clear that there's an error: see TcUnify Note [Don't skolemise unnecessarily] 8. Type.isPiTy and isForAllTy seem to be missing a coreView check, so I added it 9. Kill off tcs_used_tcvs. Its purpose is to track the givens used by wanted constraints. For dictionaries etc we do that via the free vars of the /bindings/ in the implication constraint ic_binds. But for coercions we just do update-in-place in the type, rather than generating a binding. So we need something analogous to bindings, to track what coercions we have added. That was the purpose of tcs_used_tcvs. But it only worked for a /single/ iteration, whereas we may have multiple iterations of solving an implication. Look at (the old) 'setImplicationStatus'. If the constraint is unsolved, it just drops the used_tvs on the floor. If it becomes solved next time round, we'll pick up coercions used in that round, but ignore ones used in the first round. There was an outright bug. Result = (potentialy) bogus unused-constraint errors. Constructing a case where this actually happens seems quite trick so I did not do so. Solution: expand EvBindsVar to include the (free vars of the) coercions, so that the coercions are tracked in essentially the same way as the bindings. This turned out to be much simpler. Less code, more correct. 10. Make the ic_binds field in an implication have type ic_binds :: EvBindsVar instead of (as previously) ic_binds :: Maybe EvBindsVar This is notably simpler, and faster to use -- less testing of the Maybe. But in the occaional situation where we don't have anywhere to put the bindings, the belt-and-braces error check is lost. So I put it back as an ASSERT in 'setImplicationStatus' (see the use of 'termEvidenceAllowed') All these changes led to quite bit of error message wibbling
* Testsuite: delete Roles9.stderrThomas Miedema2016-04-261-7/+0
| | | | | In 99cd277c181dfb346d5f2d5fc9475379229037d0, goldfire deleted the Roles9 test, but not its stderr file.
* SCC analysis for instances as well as types/classesSimon Peyton Jones2016-04-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This big patch is in pursuit of Trac #11348. It is largely the work of Alex Veith (thank you!), with some follow-up simplification and refactoring from Simon PJ. The main payload is described in RnSource Note [Dependency analysis of type, class, and instance decls] which is pretty detailed. * There is a new data type HsDecls.TyClGroup, for a strongly connected component of type/class/instance/role decls. The hs_instds field of HsGroup disappears, in consequence This forces some knock-on changes, including a minor haddock submodule update Smaller, weakly-related things * I found that both the renamer and typechecker were building an identical env for RoleAnnots, so I put common code for RoleAnnotEnv in RnEnv. * I found that tcInstDecls1 had very clumsy error handling, so I put it together into TcInstDcls.doClsInstErrorChecks
* Do not print DmdType in Core outputJoachim Breitner2016-03-292-15/+13
| | | | too verbose, and usualy preceded by Str= anyways.
* Move DFunUnfolding generation to TcInstDclsSimon Peyton Jones2016-03-231-4/+9
| | | | | | | | The desugarer had a fragile case to generate the Unfolding for a DFun. This patch moves the unfolding generation to TcInstDcls, where all the pieces are to hand. Fixes Trac #11742
* Track specified/invisible more carefully.Richard Eisenberg2016-03-211-2/+2
| | | | | | | | | | | | | | In particular, this allows correct tracking of specified/invisible for variables in Haskell98 data constructors and in pattern synonyms. GADT-syntax constructors are harder, and are left until #11721. This was all inspired by Simon's comments to my fix for #11512, which this subsumes. Test case: ghci/scripts/TypeAppData [skip ci] (The test case fails because of an unrelated problem fixed in the next commit.)
* Make equality print better. (#11712)Richard Eisenberg2016-03-212-2/+2
|
* Simplify: Make generated names more usefulBen Gamari2016-03-121-20/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | makeTrivial is responsible for concocting names during simplification. Previously, however, it would make no attempt to generate a name that might be useful to later readers of the resulting Core. Here we add a bit of state to SimplEnv: a finite depth stack of binders within which we are currently simplifying. We then derive generated binders from this context. See #11676. Open questions: * Is there a better way to accomplish this? * Is `maxContextDepth` too large/small? Test Plan: Validate, look at Core. Reviewers: austin, simonpj Reviewed By: simonpj Subscribers: thomie, simonpj Differential Revision: https://phabricator.haskell.org/D1970 GHC Trac Issues: #11676
* Address #11471 by putting RuntimeRep in kinds.wip/runtime-repRichard Eisenberg2016-02-244-14/+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.
* Unwire Typeable representation typesBen Gamari2016-02-181-30/+30
| | | | | | | | | | | | | | | | In order to make this work I needed to shuffle around typechecking a bit such that `TyCon` and friends are available during compilation of GHC.Types. I also did a bit of refactoring of `TcTypeable`. Test Plan: Validate Reviewers: simonpj, austin Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D1906 GHC Trac Issues: #11120
* Improve pretty-printing of HsWrappersSimon Peyton Jones2016-02-121-6/+4
| | | | | | | | Reduces un-neede parens. Also -fprint-typechecker-elaboration now makes type applications and casts in expressions also appear. (Previously those were confusingly controlled by -fprint-explicit-coercions.)
* Refactoring on IdInfo and system derived namesSimon Peyton Jones2016-01-187-60/+157
| | | | | | | | | | | | | | | | | | | | 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
* Visible type applicationRichard Eisenberg2015-12-242-16/+60
| | | | | | | | | | | | | This re-working of the typechecker algorithm is based on the paper "Visible type application", by Richard Eisenberg, Stephanie Weirich, and Hamidhasan Ahmed, to be published at ESOP'16. This patch introduces -XTypeApplications, which allows users to say, for example `id @Int`, which has type `Int -> Int`. See the changes to the user manual for details. This patch addresses tickets #10619, #5296, #10589.
* Delete incorrect *-ws-32 expected test outputErik de Castro Lopo2015-12-237-269/+0
| | | | | | | | | | | | | | | | | Summary: The *-ws-32 file were too difficult to keep up-to-date so @bgamari updated the test outut normalization code in commit 786d528e8f949d to make these files un-necessary. Test Plan: test on PowerPC Reviewers: hvr, austin, bgamari Reviewed By: bgamari Subscribers: thomie, bgamari Differential Revision: https://phabricator.haskell.org/D1690
* Add -fprint-typechecker-elaboration flag (fixes #10662)Eugene Akentyev2015-12-172-4/+5
| | | | | | | | | | | | Reviewers: thomie, austin, bgamari Reviewed By: thomie, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1625 GHC Trac Issues: #10662
* Narrow scope of special-case for unqualified printing of names in core librariesBen Gamari2015-12-157-66/+149
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Update expected test output for 32 bit platformsErik de Castro Lopo2015-12-157-132/+73
| | | | | | | | | | | | Test Plan: Run tests on a 32 bit platform Reviewers: austin, hvr, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1627
* Add kind equalities to GHC.Richard Eisenberg2015-12-118-137/+78
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Refactor treatment of wildcardsSimon Peyton Jones2015-12-011-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch began as a modest refactoring of HsType and friends, to clarify and tidy up exactly where quantification takes place in types. Although initially driven by making the implementation of wildcards more tidy (and fixing a number of bugs), I gradually got drawn into a pretty big process, which I've been doing on and off for quite a long time. There is one compiler performance regression as a result of all this, in perf/compiler/T3064. I still need to look into that. * The principal driving change is described in Note [HsType binders] in HsType. Well worth reading! * Those data type changes drive almost everything else. In particular we now statically know where (a) implicit quantification only (LHsSigType), e.g. in instance declaratios and SPECIALISE signatures (b) implicit quantification and wildcards (LHsSigWcType) can appear, e.g. in function type signatures * As part of this change, HsForAllTy is (a) simplified (no wildcards) and (b) split into HsForAllTy and HsQualTy. The two contructors appear when and only when the correponding user-level construct appears. Again see Note [HsType binders]. HsExplicitFlag disappears altogether. * Other simplifications - ExprWithTySig no longer needs an ExprWithTySigOut variant - TypeSig no longer needs a PostRn name [name] field for wildcards - PatSynSig records a LHsSigType rather than the decomposed pieces - The mysterious 'GenericSig' is now 'ClassOpSig' * Renamed LHsTyVarBndrs to LHsQTyVars * There are some uninteresting knock-on changes in Haddock, because of the HsSyn changes I also did a bunch of loosely-related changes: * We already had type synonyms CoercionN/CoercionR for nominal and representational coercions. I've added similar treatment for TcCoercionN/TcCoercionR mkWpCastN/mkWpCastN All just type synonyms but jolly useful. * I record-ised ForeignImport and ForeignExport * I improved the (poor) fix to Trac #10896, by making TcTyClsDecls.checkValidTyCl recover from errors, but adding a harmless, abstract TyCon to the envt if so. * I did some significant refactoring in RnEnv.lookupSubBndrOcc, for reasons that I have (embarrassingly) now totally forgotten. It had to do with something to do with import and export Updates haddock submodule.
* New expected test output for 32 bit platformsErik de Castro Lopo2015-11-237-0/+328
| | | | | | | | | | Test Plan: Test on Arm and PowerPc. Reviewers: bgamari, thomie, austin Differential Revision: https://phabricator.haskell.org/D1510 GHC Trac Issues: #11060
* Fix inconsistent pretty-printing of type familiesMichał Sośnicki2015-11-184-8/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | 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-016-6/+6
| | | | | | | | | | | 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-016-6/+6
| | | | | | | | | | | 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-307-5/+176
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-297-176/+5
| | | | | | | | This reverts commit bef2f03e4d56d88a7e9752a7afd6a0a35616da6c. This merge was botched Also reverts haddock submodule.
View Lorry Controller Status