summaryrefslogtreecommitdiff
path: root/compiler/prelude/PrelNames.hs
Commit message (Collapse)AuthorAgeFilesLines
...
* Update levity polymorphismRichard Eisenberg2017-01-191-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit implements the proposal in https://github.com/ghc-proposals/ghc-proposals/pull/29 and https://github.com/ghc-proposals/ghc-proposals/pull/35. Here are some of the pieces of that proposal: * Some of RuntimeRep's constructors have been shortened. * TupleRep and SumRep are now parameterized over a list of RuntimeReps. * This means that two types with the same kind surely have the same representation. Previously, all unboxed tuples had the same kind, and thus the fact above was false. * RepType.typePrimRep and friends now return a *list* of PrimReps. These functions can now work successfully on unboxed tuples. This change is necessary because we allow abstraction over unboxed tuple types and so cannot always handle unboxed tuples specially as we did before. * We sometimes have to create an Id from a PrimRep. I thus split PtrRep * into LiftedRep and UnliftedRep, so that the created Ids have the right strictness. * The RepType.RepType type was removed, as it didn't seem to help with * much. * The RepType.repType function is also removed, in favor of typePrimRep. * I have waffled a good deal on whether or not to keep VoidRep in TyCon.PrimRep. In the end, I decided to keep it there. PrimRep is *not* represented in RuntimeRep, and typePrimRep will never return a list including VoidRep. But it's handy to have in, e.g., ByteCodeGen and friends. I can imagine another design choice where we have a PrimRepV type that is PrimRep with an extra constructor. That seemed to be a heavier design, though, and I'm not sure what the benefit would be. * The last, unused vestiges of # (unliftedTypeKind) have been removed. * There were several pretty-printing bugs that this change exposed; * these are fixed. * We previously checked for levity polymorphism in the types of binders. * But we also must exclude levity polymorphism in function arguments. This is hard to check for, requiring a good deal of care in the desugarer. See Note [Levity polymorphism checking] in DsMonad. * In order to efficiently check for levity polymorphism in functions, it * was necessary to add a new bit of IdInfo. See Note [Levity info] in IdInfo. * It is now safe for unlifted types to be unsaturated in Core. Core Lint * is updated accordingly. * We can only know strictness after zonking, so several checks around * strictness in the type-checker (checkStrictBinds, the check for unlifted variables under a ~ pattern) have been moved to the desugarer. * Along the way, I improved the treatment of unlifted vs. banged * bindings. See Note [Strict binds checks] in DsBinds and #13075. * Now that we print type-checked source, we must be careful to print * ConLikes correctly. This is facilitated by a new HsConLikeOut constructor to HsExpr. Particularly troublesome are unlifted pattern synonyms that get an extra void# argument. * Includes a submodule update for haddock, getting rid of #. * New testcases: typecheck/should_fail/StrictBinds typecheck/should_fail/T12973 typecheck/should_run/StrictPats typecheck/should_run/T12809 typecheck/should_fail/T13105 patsyn/should_fail/UnliftedPSBind typecheck/should_fail/LevPolyBounded typecheck/should_compile/T12987 typecheck/should_compile/T11736 * Fixed tickets: #12809 #12973 #11736 #13075 #12987 * This also adds a test case for #13105. This test case is * "compile_fail" and succeeds, because I want the testsuite to monitor the error message. When #13105 is fixed, the test case will compile cleanly.
* Desugar static forms to makeStatic calls.Facundo Domínguez2017-01-131-0/+11
| | | | | | | | | | | | | | | | | | | Summary: Using makeStatic instead of applications of the StaticPtr data constructor makes possible linting core when unboxing strict fields. Test Plan: ./validate Reviewers: simonpj, goldfire, austin, bgamari, hvr Reviewed By: simonpj Subscribers: RyanGlScott, mboes, thomie Differential Revision: https://phabricator.haskell.org/D2930 GHC Trac Issues: #12622
* Revert "Have addModFinalizer expose the local type environment."Facundo Domínguez2017-01-061-11/+0
| | | | This reverts commit e5d1ed9c8910839e109da59820ca793642961284.
* Have addModFinalizer expose the local type environment.Facundo Domínguez2017-01-061-0/+11
| | | | | | | | | | | | | | | | | | | Summary: Kind inference in ghci was interfered when renaming of type splices introduced the HsSpliced data constructor. This patch has kind inference skip over it. Test Plan: ./validate Reviewers: simonpj, rrnewton, austin, goldfire, bgamari Reviewed By: goldfire, bgamari Subscribers: thomie, mboes Differential Revision: https://phabricator.haskell.org/D2886 GHC Trac Issues: #12985
* Clean up handling of known-key Names in interface filesBen Gamari2016-10-131-19/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously BinIface had some dedicated logic for handling tuple names in the symbol table. As it turns out, this logic was essentially dead code as it was superceded by the special handling of known-key things. Here we cull the tuple code-path and use the known-key codepath for all tuple-ish things. This had a surprising number of knock-on effects, * constraint tuple datacons had to be made known-key (previously they were not) * IfaceTopBndr was changed from being a synonym of OccName to a synonym of Name (since we now need to be able to deserialize Names directly from interface files) * the change to IfaceTopBndr complicated fingerprinting, since we need to ensure that we don't go looking for the fingerprint of the thing we are currently fingerprinting in the fingerprint environment (see notes in MkIface). Handling this required distinguishing between binding and non-binding Name occurrences in the Binary serializers. * the original name cache logic which previously lived in IfaceEnv has been moved to a new NameCache module * I ripped tuples and sums out of knownKeyNames since they introduce a very large number of entries. During interface file deserialization we use static functions (defined in the new KnownUniques module) to map from a Unique to a known-key Name (the Unique better correspond to a known-key name!) When we need to do an original name cache lookup we rely on the parser implemented in isBuiltInOcc_maybe. * HscMain.allKnownKeyNames was folded into PrelInfo.knownKeyNames. * Lots of comments were sprinkled about describing the new scheme. Updates haddock submodule. Test Plan: Validate Reviewers: niteria, simonpj, austin, hvr Reviewed By: simonpj Subscribers: simonmar, niteria, thomie Differential Revision: https://phabricator.haskell.org/D2467 GHC Trac Issues: #12532, #12415
* Turn divInt# and modInt# into bitwise operations when possibleTakano Akio2016-09-051-1/+11
| | | | | | | | | | | | | | | | | | | This implements #5615 for divInt# and modInt#. I also included rules to do constant-folding when the both arguments are known. Test Plan: validate Reviewers: austin, simonmar, bgamari Reviewed By: bgamari Subscribers: hvr, thomie Differential Revision: https://phabricator.haskell.org/D2486 GHC Trac Issues: #5615
* Support for noinline magic function.Edward Z. Yang2016-08-211-1/+4
| | | | | | | | | | | | Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonpj, austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2209
* Remove StgRubbishArg and CmmArgÖmer Sinan Ağacan2016-08-101-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The idea behind adding special "rubbish" arguments was in unboxed sum types depending on the tag some arguments are not used and we don't want to move some special values (like 0 for literals and some special pointer for boxed slots) for those arguments (to stack locations or registers). "StgRubbishArg" was an indicator to the code generator that the value won't be used. During Stg-to-Cmm we were then not generating any move or store instructions at all. This caused problems in the register allocator because some variables were only initialized in some code paths. As an example, suppose we have this STG: (after unarise) Lib.$WT = \r [dt_sit] case case dt_sit of { Lib.F dt_siv [Occ=Once] -> (#,,#) [1# dt_siv StgRubbishArg::GHC.Prim.Int#]; Lib.I dt_siw [Occ=Once] -> (#,,#) [2# StgRubbishArg::GHC.Types.Any dt_siw]; } of dt_six { (#,,#) us_giC us_giD us_giE -> Lib.T [us_giC us_giD us_giE]; }; This basically unpacks a sum type to an unboxed sum with 3 fields, and then moves the unboxed sum to a constructor (`Lib.T`). This is the Cmm for the inner case expression (case expression in the scrutinee position of the outer case): ciN: ... -- look at dt_sit's tag if (_ciT::P64 != 1) goto ciS; else goto ciR; ciS: -- Tag is 2, i.e. Lib.F _siw::I64 = I64[_siu::P64 + 6]; _giE::I64 = _siw::I64; _giD::P64 = stg_RUBBISH_ENTRY_info; _giC::I64 = 2; goto ciU; ciR: -- Tag is 1, i.e. Lib.I _siv::P64 = P64[_siu::P64 + 7]; _giD::P64 = _siv::P64; _giC::I64 = 1; goto ciU; Here one of the blocks `ciS` and `ciR` is executed and then the execution continues to `ciR`, but only `ciS` initializes `_giE`, in the other branch `_giE` is not initialized, because it's "rubbish" in the STG and so we don't generate an assignment during code generator. The code generator then panics during the register allocations: ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.1.20160722 for x86_64-unknown-linux): LocalReg's live-in to graph ciY {_giE::I64} (`_giD` is also "rubbish" in `ciS`, but it's still initialized because it's a pointer slot, we have to initialize it otherwise garbage collector follows the pointer to some random place. So we only remove assignment if the "rubbish" arg has unboxed type.) This patch removes `StgRubbishArg` and `CmmArg`. We now always initialize rubbish slots. If the slot is for boxed types we use the existing `absentError`, otherwise we initialize the slot with literal 0. Reviewers: simonpj, erikd, austin, simonmar, bgamari Reviewed By: erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2446
* Implement unboxed sum primitive typeÖmer Sinan Ağacan2016-07-211-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch implements primitive unboxed sum types, as described in https://ghc.haskell.org/trac/ghc/wiki/UnpackedSumTypes. Main changes are: - Add new syntax for unboxed sums types, terms and patterns. Hidden behind `-XUnboxedSums`. - Add unlifted unboxed sum type constructors and data constructors, extend type and pattern checkers and desugarer. - Add new RuntimeRep for unboxed sums. - Extend unarise pass to translate unboxed sums to unboxed tuples right before code generation. - Add `StgRubbishArg` to `StgArg`, and a new type `CmmArg` for better code generation when sum values are involved. - Add user manual section for unboxed sums. Some other changes: - Generalize `UbxTupleRep` to `MultiRep` and `UbxTupAlt` to `MultiValAlt` to be able to use those with both sums and tuples. - Don't use `tyConPrimRep` in `isVoidTy`: `tyConPrimRep` is really wrong, given an `Any` `TyCon`, there's no way to tell what its kind is, but `kindPrimRep` and in turn `tyConPrimRep` returns `PtrRep`. - Fix some bugs on the way: #12375. Not included in this patch: - Update Haddock for new the new unboxed sum syntax. - `TemplateHaskell` support is left as future work. For reviewers: - Front-end code is mostly trivial and adapted from unboxed tuple code for type checking, pattern checking, renaming, desugaring etc. - Main translation routines are in `RepType` and `UnariseStg`. Documentation in `UnariseStg` should be enough for understanding what's going on. Credits: - Johan Tibell wrote the initial front-end and interface file extensions. - Simon Peyton Jones reviewed this patch many times, wrote some code, and helped with debugging. Reviewers: bgamari, alanz, goldfire, RyanGlScott, simonpj, austin, simonmar, hvr, erikd Reviewed By: simonpj Subscribers: Iceland_jack, ggreif, ezyang, RyanGlScott, goldfire, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D2259
* Revert "Clean up interaction between name cache and built-in syntax"Ben Gamari2016-07-201-2/+1
| | | | | | This reverts commit 9513fe6bdeafd35ca1a04e17b5f94732516766aa. Sadly this broke with -DDEBUG.
* Compact RegionsGiovanni Campagna2016-07-201-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | This brings in initial support for compact regions, as described in the ICFP 2015 paper "Efficient Communication and Collection with Compact Normal Forms" (Edward Z. Yang et.al.) and implemented by Giovanni Campagna. Some things may change before the 8.2 release, but I (Simon M.) wanted to get the main patch committed so that we can iterate. What documentation there is is in the Data.Compact module in the new compact package. We'll need to extend and polish the documentation before the release. Test Plan: validate (new test cases included) Reviewers: ezyang, simonmar, hvr, bgamari, austin Subscribers: vikraman, Yuras, RyanGlScott, qnikst, mboes, facundominguez, rrnewton, thomie, erikd Differential Revision: https://phabricator.haskell.org/D1264 GHC Trac Issues: #11493
* Clean up interaction between name cache and built-in syntaxBen Gamari2016-07-201-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This cleans up various aspects of the handling of built-in syntax in the original name cache (hopefully resulting in a nice reduction in compiler allocations), * Remove tuple types from original name cache: There is really no reason for these to be in the name cache since we already handle them specially in interface files to ensure that we can resolve them directly to Names, avoiding extraneous name cache lookups. * Sadly it's not possible to remove all traces of tuples from the name cache, however. Namely we need to keep the tuple type representations in since otherwise they would need to be wired-in * Remove the special cases for (:), [], and (##) in isBuiltInOcc_maybe and rename it to isTupleOcc_maybe * Split lookupOrigNameCache into two variants, * lookupOrigNameCache': Merely looks up an OccName in the original name cache, making no attempt to resolve tuples * lookupOrigNameCache: Like the above but handles tuples as well. This is given the un-primed name since it does the "obvious" thing from the perspective of an API user, who knows nothing of our special treatment of tuples. Arriving at this design took a significant amount of iteration. The trail of debris leading here can be found in #11357. Thanks to ezyang and Simon for all of their help in coming to this solution. Test Plan: Validate Reviewers: goldfire, simonpj, austin Reviewed By: simonpj Subscribers: thomie, ezyang Differential Revision: https://phabricator.haskell.org/D2414 GHC Trac Issues: #11357
* Fix #11974 by adding a more smarts to TcDefaults.Richard Eisenberg2016-06-231-0/+12
| | | | | | Test cases: typecheck/should_compile/T11974 typecheck/should_fail/T11974b
* Kill the magic of AnyBen Gamari2016-03-301-8/+10
| | | | | | | | | | | | | | | | | | | | This turns `Any` into a standard wired-in type family defined in `GHC.Types`, instead its current incarnation as a magical creature provided by the `GHC.Prim`. Also kill `AnyK`. See #10886. Test Plan: Validate Reviewers: simonpj, goldfire, austin, hvr Reviewed By: simonpj Subscribers: goldfire, thomie Differential Revision: https://phabricator.haskell.org/D2049 GHC Trac Issues: #10886
* Overload the static form to reduce verbosity.Facundo Domínguez2016-02-251-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Static pointers are rarely used naked: most often they are defined at the base of a Closure, as defined in e.g. the distributed-closure and distributed-static packages. So a typical usage pattern is: distributeMap (closure (static (\x -> x * 2))) which is more verbose than it needs to be. Ideally we'd just have to write distributeMap (static (\x -> x * 2)) and let the static pointer be lifted to a Closure implicitly. i.e. what we want is to overload static literals, just like we already overload list literals and string literals. This is achieved by introducing the IsStatic type class and changing the typing rule for static forms slightly: static (e :: t) :: IsStatic p => p t Test Plan: ./validate Reviewers: austin, hvr, bgamari Reviewed By: bgamari Subscribers: simonpj, mboes, thomie Differential Revision: https://phabricator.haskell.org/D1923 GHC Trac Issues: #11585
* Address #11471 by putting RuntimeRep in kinds.wip/runtime-repRichard Eisenberg2016-02-241-10/+28
| | | | | | | | | | | | | | | | | | | | | 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-0/+22
| | | | | | | | | | | | | | | | 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
* Rework derivation of type representations for wired-in thingsBen Gamari2016-01-201-23/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously types defined by `GHC.Types` and `GHC.Prim` had their `Typeable` representations manually defined in `GHC.Typeable.Internals`. This was terrible, resulting in a great deal of boilerplate and a number of bugs due to missing or inconsistent representations (see #11120). Here we take a different tack, initially proposed by Richard Eisenberg: We wire-in the `Module`, `TrName`, and `TyCon` types, allowing them to be used in `GHC.Types`. We then allow the usual type representation generation logic to handle this module. `GHC.Prim`, on the other hand, is a bit tricky as it has no object code of its own. To handle this we instead place the type representations for the types defined here in `GHC.Types`. On the whole this eliminates several special-cases as well as a fair amount of boilerplate from hand-written representations. Moreover, we get full coverage of primitive types for free. Test Plan: Validate Reviewers: goldfire, simonpj, austin, hvr Subscribers: goldfire, simonpj, thomie Differential Revision: https://phabricator.haskell.org/D1774 GHC Trac Issues: #11120
* un-wire-in error, undefined, CallStack, and IPEric Seidel2016-01-181-17/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | I missed a crucial step in the wiring-in process of `CallStack` in D861, the bit where you actually wire-in the Name... This led to a nasty bug where GHC thought `CallStack` was not wired-in and tried to fingerprint it, which failed because the defining module was not loaded. But we don't need `CallStack` to be wired-in anymore since `error` and `undefined` no longer need to be wired-in. So we just remove them all. Updates haddock submodule. Test Plan: `./validate` and `make slowtest TEST=tc198` Reviewers: simonpj, goldfire, austin, hvr, bgamari Reviewed By: simonpj, bgamari Subscribers: goldfire, thomie Projects: #ghc Differential Revision: https://phabricator.haskell.org/D1739 GHC Trac Issues: #11331
* Add missing type representationsBen Gamari2016-01-131-23/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | Previously we were missing `Typeable` representations for several wired-in types (and their promoted constructors). These include, * `Nat` * `Symbol` * `':` * `'[]` Moreover, some constructors were incorrectly identified as being defined in `GHC.Types` whereas they were in fact defined in `GHC.Prim`. Ultimately this is just a temporary band-aid as there is general agreement that we should eliminate the manual definition of these representations entirely. Test Plan: Validate Reviewers: austin, hvr Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1769 GHC Trac Issues: #11120
* Allow CallStacks to be frozenEric Seidel2015-12-231-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This introduces "freezing," an operation which prevents further locations from being appended to a CallStack. Library authors may want to prevent CallStacks from exposing implementation details, as a matter of hygiene. For example, in ``` head [] = error "head: empty list" ghci> head [] *** Exception: head: empty list CallStack (from implicit params): error, called at ... ``` including the call-site of `error` in `head` is not strictly necessary as the error message already specifies clearly where the error came from. So we add a function `freezeCallStack` that wraps an existing CallStack, preventing further call-sites from being pushed onto it. In other words, ``` pushCallStack callSite (freezeCallStack callStack) = freezeCallStack callStack ``` Now we can define `head` to not produce a CallStack at all ``` head [] = let ?callStack = freezeCallStack emptyCallStack in error "head: empty list" ghci> head [] *** Exception: head: empty list CallStack (from implicit params): error, called at ... ``` --- 1. We add the `freezeCallStack` and `emptyCallStack` and update the definition of `CallStack` to support this functionality. 2. We add `errorWithoutStackTrace`, a variant of `error` that does not produce a stack trace, using this feature. I think this is a sensible wrapper function to provide in case users want it. 3. We replace uses of `error` in base with `errorWithoutStackTrace`. The rationale is that base does not export any functions that use CallStacks (except for `error` and `undefined`) so there's no way for the stack traces (from Implicit CallStacks) to include user-defined functions. They'll only contain the call to `error` itself. As base already has a good habit of providing useful error messages that name the triggering function, the stack trace really just adds noise to the error. (I don't have a strong opinion on whether we should include this third commit, but the change was very mechanical so I thought I'd include it anyway in case there's interest) 4. Updates tests in `array` and `stm` submodules Test Plan: ./validate, new test is T11049 Reviewers: simonpj, nomeata, goldfire, austin, hvr, bgamari Reviewed By: simonpj Subscribers: thomie Projects: #ghc Differential Revision: https://phabricator.haskell.org/D1628 GHC Trac Issues: #11049
* Encode strictness in GHC generics metadataRyanGlScott2015-12-211-11/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This augments `MetaSel` with a `Bang` field, which gives generic programmers access to the following information about each field selector: * `SourceUnpackedness`: whether a field was marked `{-# NOUNPACK #-}`, `{-# UNPACK #-}`, or not * `SourceStrictness`: whether a field was given a strictness (`!`) or laziness (`~`) annotation * `DecidedStrictness`: what strictness GHC infers for a field during compilation, which may be influenced by optimization levels, `-XStrictData`, `-funbox-strict-fields`, etc. Unlike in Phab:D1603, generics does not grant a programmer the ability to "splice" in metadata, so there is no issue including `DecidedStrictness` with `Bang` (whereas in Template Haskell, it had to be split off). One consequence of this is that `MetaNoSel` had to be removed, since it became redundant. The `NoSelector` empty data type was also removed for similar reasons. Fixes #10716. Test Plan: ./validate Reviewers: dreixel, goldfire, kosmikus, austin, hvr, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1646 GHC Trac Issues: #10716
* Note [The equality types story] in TysPrimRichard Eisenberg2015-12-161-1/+1
| | | | This supercedes the Note recently written in TysWiredIn.
* Frontend plugins.Edward Z. Yang2015-12-121-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Frontend plugins enable users to write plugins to replace GHC major modes. E.g. instead of saying ghc --make A B C a user can now say ghc --frontend GHC.Frontend.Shake A B C which might provide an alternative implementation of a multi-module build. For more details, see the manual entry. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonmar, bgamari, austin, simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1598 GHC Trac Issues: #11194
* Add kind equalities to GHC.Richard Eisenberg2015-12-111-61/+86
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Use TypeLits in the meta-data encoding of GHC.GenericsRyanGlScott2015-12-071-16/+43
| | | | | | | | | | | | | | Test Plan: Validate. Reviewers: simonpj, goldfire, hvr, dreixel, kosmikus, austin, bgamari Reviewed By: kosmikus, austin, bgamari Subscribers: RyanGlScott, Fuuzetsu, bgamari, thomie, carter, dreixel Differential Revision: https://phabricator.haskell.org/D493 GHC Trac Issues: #9766
* Refactor treatment of wildcardsSimon Peyton Jones2015-12-011-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Implement warnings for Semigroups as parent of MonoidDavid Luposchainsky2015-11-291-1/+28
| | | | | | | | | | | | | | | | | | | | | This patch is similar to the AMP patch (#8004), which offered two functions: 1. Warn when an instance of a class has been given, but the type does not have a certain superclass instance 2. Warn when top-level definitions conflict with future Prelude names These warnings are issued as part of the new `-Wcompat` warning group. Reviewers: hvr, ekmett, austin, bgamari Reviewed By: hvr, ekmett, bgamari Subscribers: ekmett, thomie Differential Revision: https://phabricator.haskell.org/D1539 GHC Trac Issues: #11139
* Add `PrelNames.thenAName` for `Applicative(*>)`Herbert Valerio Riedel2015-11-241-11/+17
| | | | | | | | | | | This is needed to allow subsequent patches to refer to `*>`. While at it, this commit also groups together the `Applicative` definitions to reduce confusion. Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D1513
* MonadFail proposal, phase 1David Luposchainsky2015-11-171-12/+27
| | | | | | | | | | | | | | | | | | | | | | | | | This implements phase 1 of the MonadFail proposal (MFP, #10751). - MonadFail warnings are all issued as desired, tunable with two new flags - GHC was *not* made warning-free with `-fwarn-missing-monadfail-warnings` (but it's disabled by default right now) Credits/thanks to - Franz Thoma, whose help was crucial to implementing this - My employer TNG Technology Consulting GmbH for partially funding us for this work Reviewers: goldfire, austin, #core_libraries_committee, hvr, bgamari, fmthoma Reviewed By: hvr, bgamari, fmthoma Subscribers: thomie Projects: #ghc Differential Revision: https://phabricator.haskell.org/D1248 GHC Trac Issues: #10751
* Implement OverloadedLabelsAdam Gundry2015-11-171-0/+15
| | | | | | | | | | | | | | See https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/OverloadedLabels for the big picture. Reviewers: goldfire, simonpj, austin, hvr, bgamari Reviewed By: simonpj, bgamari Subscribers: kosmikus, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D1331
* Implement support for user-defined type errors.Iavor S. Diatchki2015-11-161-0/+47
| | | | | | | | | | | | | | | | | | | | | Implements Lennart's idea from the Haskell Symposium. Users may use the special type function `TypeError`, which is similar to `error` at the value level. See Trac ticket https://ghc.haskell.org/trac/ghc/ticket/9637, and wiki page https://ghc.haskell.org/trac/ghc/wiki/CustomTypeErros Test Plan: Included testcases Reviewers: simonpj, austin, hvr, goldfire, bgamari Reviewed By: goldfire, bgamari Subscribers: adamgundry, thomie Differential Revision: https://phabricator.haskell.org/D1236 GHC Trac Issues: #9637
* New magic function for applying realWorld#Ben Gamari2015-11-121-1/+2
| | | | | | | | | | | | | | Test Plan: validate Reviewers: goldfire, erikd, rwbarton, simonpj, austin, simonmar, hvr Reviewed By: simonpj Subscribers: simonmar, thomie Differential Revision: https://phabricator.haskell.org/D1103 GHC Trac Issues: #10678
* Generate Typeable info at definition sitesBen Gamari2015-10-301-22/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-66/+22
| | | | | | | | This reverts commit bef2f03e4d56d88a7e9752a7afd6a0a35616da6c. This merge was botched Also reverts haddock submodule.
* Generate Typeable info at definition sitesBen Gamari2015-10-291-22/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* PrelNames: Fix duplicate uniqueBen Gamari2015-10-271-1/+1
| | | | | Previously unboundKey and fromIntegerClassOpKey were sharing a Unique Reassign unboundKey to `mkPreludeMiscIdUnique 158`
* Rename package key to unit ID, and installed package ID to component ID.Edward Z. Yang2015-10-141-9/+9
| | | | | | Comes with Haddock submodule update. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
* Make GHC generics capable of handling unboxed typesRyanGlScott2015-10-031-13/+52
| | | | | | | | | | | | | | | | | | | | | | | | This adds a data family (`URec`) and six data family instances (`UAddr`, `UChar`, `UDouble`, `UFloat`, `UInt`, and `UWord`) which a `deriving Generic(1)` clause will generate if it sees `Addr#`, `Char#`, `Double#`, `Float#`, `Int#`, or `Word#`, respectively. The programmer can then provide instances for these data family instances to provide custom implementations for unboxed types, similar to how derived `Eq`, `Ord`, and `Show` instances currently special-case unboxed types. Fixes #10868. Test Plan: ./validate Reviewers: goldfire, dreixel, bgamari, austin, hvr, kosmikus Reviewed By: dreixel, kosmikus Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D1239 GHC Trac Issues: #10868
* Move CallStack back to baseBen Gamari2015-10-021-4/+5
| | | | | | | | | | | | | | | CallStack requires tuples, instances of which are defined in GHC.Tuple. Unfortunately the change made in D757 to the `Typeable` deriving mechanism means that `GHC.Tuple` must import `GHC.Types` for types necessary to generate type representations. This results in a cycle. Test Plan: Validate Reviewers: gridaphobe, austin, hvr Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1298
* Add constant-folding rule for Data.Bits.bitBen Gamari2015-09-231-2/+6
| | | | | | | | | | | This adds a constant-folding rule for `Integer`'s implementation of `bit` and fixes the `T8832` testcase. Fixes #8832. Reviewed By: simonpj, austin Differential Revision: https://phabricator.haskell.org/D1255 GHC Trac Issues: #8832
* DeriveLift extension (#1830)RyanGlScott2015-09-211-0/+9
| | | | | | | | | | | | | | | | | | | | Summary: This implements -XDeriveLift, which allows for automatic derivation of the Lift class from template-haskell. The implementation is based off of Ian Lynagh's th-lift library (http://hackage.haskell.org/package/th-lift). Test Plan: ./validate Reviewers: hvr, simonpj, bgamari, goldfire, austin Reviewed By: goldfire, austin Subscribers: osa1, thomie Differential Revision: https://phabricator.haskell.org/D1168 GHC Trac Issues: #1830
* Injective type familiesJan Stolarek2015-09-031-12/+14
| | | | | | | | | | | | | | | | | | | For details see #6018, Phab:D202 and the wiki page: https://ghc.haskell.org/trac/ghc/wiki/InjectiveTypeFamilies This patch also wires-in Maybe data type and updates haddock submodule. Test Plan: ./validate Reviewers: simonpj, goldfire, austin, bgamari Subscribers: mpickering, bgamari, alanz, thomie, goldfire, simonmar, carter Differential Revision: https://phabricator.haskell.org/D202 GHC Trac Issues: #6018
* Use IP based CallStack in error and undefinedEric Seidel2015-09-021-13/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch modifies `error`, `undefined`, and `assertError` to use implicit call-stacks to provide better error messages to users. There are a few knock-on effects: - `GHC.Classes.IP` is now wired-in so it can be used in the wired-in types for `error` and `undefined`. - `TysPrim.tyVarList` has been replaced with a new function `TysPrim.mkTemplateTyVars`. `tyVarList` made it easy to introduce subtle bugs when you need tyvars of different kinds. The naive ``` tv1 = head $ tyVarList kind1 tv2 = head $ tyVarList kind2 ``` would result in `tv1` and `tv2` sharing a `Unique`, thus substitutions would be applied incorrectly, treating `tv1` and `tv2` as the same tyvar. `mkTemplateTyVars` avoids this pitfall by taking a list of kinds and producing a single tyvar of each kind. - The types `GHC.SrcLoc.SrcLoc` and `GHC.Stack.CallStack` now live in ghc-prim. - The type `GHC.Exception.ErrorCall` has a new constructor `ErrorCallWithLocation` that takes two `String`s instead of one, the 2nd one being arbitrary metadata about the error (but usually the call-stack). A bi-directional pattern synonym `ErrorCall` continues to provide the old API. Updates Cabal, array, and haddock submodules. Reviewers: nh2, goldfire, simonpj, hvr, rwbarton, austin, bgamari Reviewed By: simonpj Subscribers: rwbarton, rodlogic, goldfire, maoe, simonmar, carter, liyang, bgamari, thomie Differential Revision: https://phabricator.haskell.org/D861 GHC Trac Issues: #5273
* PrelNames: introduce dcQual in place of conNameBen Gamari2015-08-271-20/+18
|
* PrelNames: Clean up list a bitBen Gamari2015-08-261-10/+11
|
* Remove runSTRep from PrelNamesReid Barton2015-07-271-7/+2
| | | | | | | | | | | | | | | It has no special treatment in the compiler any more. The last use was removed in 99d4e5b4a0bd "Implement cardinality analysis". Test Plan: validate Reviewers: austin, bgamari, simonpj Reviewed By: simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1099
* Handle Char#, Addr# in TH quasiquoter (fixes #10620)RyanGlScott2015-07-171-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DsMeta does not attempt to handle quasiquoted Char# or Addr# values, which causes expressions like `$([| 'a'# |])` or `$([| "abc"# |])` to fail with an `Exotic literal not (yet) handled by Template Haskell` error. To fix this, the API of `template-haskell` had to be changed so that `Lit` now has an extra constructor `CharPrimL` (a `StringPrimL` constructor already existed, but it wasn't used). In addition, `DsMeta` has to manipulate `CoreExpr`s directly that involve `Word8`s. In order to do this, `Word8` had to be added as a wired-in type to `TysWiredIn`. Actually converting from `HsCharPrim` and `HsStringPrim` to `CharPrimL` and `StringPrimL`, respectively, is pretty straightforward after that, since both `HsCharPrim` and `CharPrimL` use `Char` internally, and `HsStringPrim` uses a `ByteString` internally, which can easily be converted to `[Word8]`, which is what `StringPrimL` uses. Reviewers: goldfire, austin, simonpj, bgamari Reviewed By: simonpj, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1054 GHC Trac Issues: #10620
* Deferred type errors now throw TypeError (#10284)David Kraeutmann2015-07-071-1/+4
| | | | | | | | | | | | | | | | | | | | | | Depends on D864. Previous behaviour was ErrorCall, which might mask issues in tests using -fdefer-type-errors Signed-off-by: David Kraeutmann <kane@kane.cx> Test Plan: Test whether the error thrown is indeed TypeError and not ErrorCall. Reviewers: hvr, nomeata, austin Reviewed By: nomeata, austin Subscribers: nomeata, simonpj, thomie Differential Revision: https://phabricator.haskell.org/D866 GHC Trac Issues: #10284
* Change `Typeable` instance for type-lis to use the Known* classes.Iavor S. Diatchki2015-06-211-9/+15
| | | | This should fix T10348
View Lorry Controller Status