summaryrefslogtreecommitdiff
path: root/compiler/prelude
Commit message (Collapse)AuthorAgeFilesLines
...
* KnownUniques: Handle DataCon wrapper namesBen Gamari2017-08-011-3/+6
| | | | | | | | | | | | | | | | | For some reason these weren't handled. I seem to remember thinking I had a reason for omitting them when writing the original patch, but I don't recall what that reason was at this point and clearly workers do show up in interface files. Test Plan: Validate against T14051 Reviewers: austin Subscribers: rwbarton, thomie, RyanGlScott GHC Trac Issues: #14051 Differential Revision: https://phabricator.haskell.org/D3805
* A bunch of typofixesGabor Greif2017-07-311-1/+1
|
* Merge types and kinds in DsMetaRyan Scott2017-07-281-65/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Types and kinds are now the same in GHC... well, except in the code that involves Template Haskell, where types and kinds are given separate treatment. This aims to unify that treatment in the `DsMeta` module. The gist of this patch is replacing all uses of `repLKind` with `repLTy`. This is isn't quite as simple as one might imagine, since `repLTy` returns a `Core (Q Type)` (a monadic expression), whereas `repLKind` returns a `Core Kind` (a pure expression). This causes many awkward impedance mismatches. One option would be to change every combinator in `Language.Haskell.TH.Lib` to take `KindQ` as an argument instead of `Kind`. But this would be a breaking change of colossal proportions. Instead, this patch takes a somewhat different approach. This migrates the existing `Language.Haskell.TH.Lib` module to `Language.Haskell.TH.Lib.Internal`, and changes all `Kind`-related combinators in `Language.Haskell.TH.Lib.Internal` to live in `Q`. The new `Language.Haskell.TH.Lib` module then re-exports most of `Language.Haskell.TH.Lib.Internal` with the exception of the `Kind`-related combinators, for which it redefines them to be their current definitions (which don't live in `Q`). This allows us to retain backwards compatibility with previous `template-haskell` releases, but more importantly, it allows GHC to make as many changes to the `Internal` code as it wants for its purposes without fear of disrupting the public API. This solves half of #11785 (the other half being `TcSplice`). Test Plan: ./validate Reviewers: goldfire, austin, bgamari Reviewed By: goldfire Subscribers: rwbarton, thomie GHC Trac Issues: #11785 Differential Revision: https://phabricator.haskell.org/D3751
* Fix note references and some typosGabor Greif2017-07-261-1/+1
|
* Add Template Haskell support for overloaded labelsMatthew Pickering2017-07-111-2/+6
| | | | | | | | | | Reviewers: RyanGlScott, austin, goldfire, bgamari Reviewed By: RyanGlScott, goldfire, bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3715
* Make ':info Coercible' display an arbitrary string (fixes #12390)Patrick Dougherty2017-07-112-2/+19
| | | | | | | | | | | | | | | | | | | | This change enables the addition of an arbitrary string to the output of GHCi's ':info'. It was made for Coercible in particular but could be extended if desired. Updates haddock submodule. Test Plan: Modified test 'ghci059' to match new output. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: goldfire, rwbarton, thomie GHC Trac Issues: #12390 Differential Revision: https://phabricator.haskell.org/D3634
* Reword documentation region overlap documentation for copying mutable arraysAndrew Martin2017-06-191-6/+14
|
* Support signatures at the kind level in Template HaskellRyan Scott2017-06-121-13/+19
| | | | | | | | | | | | | | | | | `repNonArrowKind` was missing a case for `HsKindSig`, which this commit adds. Fixes #13781. Test Plan: make test TEST=T13781 Reviewers: goldfire, austin, bgamari Reviewed By: goldfire Subscribers: rwbarton, thomie GHC Trac Issues: #13781 Differential Revision: https://phabricator.haskell.org/D3627
* Use lengthIs and friends in more placesRyan Scott2017-06-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | While investigating #12545, I discovered several places in the code that performed length-checks like so: ``` length ts == 4 ``` This is not ideal, since the length of `ts` could be much longer than 4, and we'd be doing way more work than necessary! There are already a slew of helper functions in `Util` such as `lengthIs` that are designed to do this efficiently, so I found every place where they ought to be used and did just that. I also defined a couple more utility functions for list length that were common patterns (e.g., `ltLength`). Test Plan: ./validate Reviewers: austin, hvr, goldfire, bgamari, simonmar Reviewed By: bgamari, simonmar Subscribers: goldfire, rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3622
* A few typos [ci skip]Gabor Greif2017-06-021-1/+1
|
* Prefer #if defined to #ifdefBen Gamari2017-04-281-1/+1
| | | | Our new CPP linter enforces this.
* Improve code generation for conditionalsSimon Peyton Jones2017-04-281-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch in in preparation for the fix to Trac #13397 The code generator has a special case for case tagToEnum (a>#b) of False -> e1 True -> e2 but it was not doing nearly so well on case a>#b of DEFAULT -> e1 1# -> e2 This patch arranges to behave essentially identically in both cases. In due course we can eliminate the special case for tagToEnum#, once we've completed Trac #13397. The changes are: * Make CmmSink swizzle the order of a conditional where necessary; see Note [Improving conditionals] in CmmSink * Hack the general case of StgCmmExpr.cgCase so that it use NoGcInAlts for conditionals. This doesn't seem right, but it's the same choice as the tagToEnum version. Without it, code size increases a lot (more heap checks). There's a loose end here. * Add comments in CmmOpt.cmmMachOpFoldM
* Re-engineer caseRules to add tagToEnum/dataToTagSimon Peyton Jones2017-04-281-82/+149
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | See Note [Scrutinee Constant Folding] in SimplUtils * Add cases for tagToEnum and dataToTag. This is the main new bit. It allows the simplifier to remove the pervasive uses of case tagToEnum (a > b) of False -> e1 True -> e2 and replace it by the simpler case a > b of DEFAULT -> e1 1# -> e2 See Note [caseRules for tagToEnum] and Note [caseRules for dataToTag] in PrelRules. * This required some changes to the API of caseRules, and hence to code in SimplUtils. See Note [Scrutinee Constant Folding] in SimplUtils. * Avoid duplication of work in the (unusual) case of case BIG + 3# of b DEFAULT -> e1 6# -> e2 Previously we got case BIG of DEFAULT -> let b = BIG + 3# in e1 3# -> let b = 6# in e2 Now we get case BIG of b# DEFAULT -> let b = b' + 3# in e1 3# -> let b = 6# in e2 * Avoid duplicated code in caseRules A knock-on refactoring: * Move Note [Word/Int underflow/overflow] to Literal, as documentation to accompany mkMachIntWrap etc; and get rid of PrelRuls.intResult' in favour of mkMachIntWrap
* Document mkWeak#Ben Gamari2017-04-251-0/+5
| | | | | | | | | | | | Reviewers: simonmar, austin Reviewed By: simonmar Subscribers: RyanGlScott, rwbarton, thomie GHC Trac Issues: #10640, #13611 Differential Revision: https://phabricator.haskell.org/D3498
* base: Implement bit casts between word and float typesErik de Castro Lopo2017-04-121-2/+3
| | | | | | | | | | | | | Test Plan: Test on x86 and x86_64 Reviewers: duncan, trofi, simonmar, tibbe, hvr, austin, rwbarton, bgamari Reviewed By: duncan Subscribers: Phyx, DemiMarie, rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3358
* Revert "Make raiseIO# produce topRes"David Feuer2017-04-031-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit da4687f63ffe5a6162e3d7856aa53de048dd0f42. It's not entirely trivial to clean up the dead code this patch introduced. In particular, when we see ``` case raiseIO# m s of s' -> e ``` we want to know that `e` is dead. For scrutinees that are properly bottom (which we don't want to consider `raiseIO# m s` to be, this is handled by rewriting `bot` to `case bot of {}`. But if we do that for `raiseIO#`, we end up with ``` case raiseIO# m s of {} ``` which looks a lot like bottom and could confuse demand analysis. I think we need to wait with this change until we have a more complete story. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3413
* Derive the definition of nullDavid Feuer2017-04-021-1/+4
| | | | | | | | | | | | | | | | | | | | | | | We can sometimes produce much better code by deriving the definition of `null` rather than using the default. For example, given data SnocList a = Lin | Snoc (SnocList a) a the default definition of `null` will walk the whole list, but of course we can stop as soon as we see `Snoc`. Similarly, if a constructor contains some other `Foldable` type, we want to use its `null` rather than folding over the structure. Partially fixes Trac #13280 Reviewers: austin, bgamari, RyanGlScott Reviewed By: RyanGlScott Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3402
* Don't derive showListDavid Feuer2017-04-011-5/+2
| | | | | | | | | | | | | | | | | There's no obvious reason to derive the definition of `showList`, manually inlining the default definition. Let's just use the default definition in the usual manner. Garbage collect a few unused `RdrNames` from `PrelNames`: `showList`, `showList__`, and `/=`. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: RyanGlScott, rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3403
* Typos in comments [ci skip]Gabor Greif2017-03-301-1/+1
|
* Spelling in comments only [ci skip]Gabor Greif2017-03-282-2/+2
|
* Make unsafeInterleaveST less unsafeDavid Feuer2017-03-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | * Make `unsafeInterleaveST` use `noDuplicate#` like `unsafeInterleaveIO` does to prevent the suspended action from being run in two threads. * In order to accomplish this without `unsafeCoerce#`, generalize the type of `noDuplicate#`. * Add `unsafeDupableInterleaveST` to get the old behavior. * Document unsafe `ST` functions and clean up some related documentation. Fixes #13457 Reviewers: austin, hvr, bgamari, ekmett Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3370
* Let GHC know MutVar# ops can't failDavid Feuer2017-03-211-2/+16
| | | | | | | | | | | | | | | | | The only way `readMutVar#` or `writeMutVar#` can fail is if its argument is not a valid pointer. I believe we ensure this by construction, and never test for pointer validity. So I think it should be safe to say that it can't fail. Fixes #13424 Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3340
* No join-point from an INLINE function with wrong aritySimon Peyton Jones2017-03-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | The main payload of this patch is NOT to make a join-point from a function with an INLINE pragma and the wrong arity; see Note [Join points and INLINE pragmas] in CoreOpt. This is what caused Trac #13413. But we must do the exact same thing in simpleOptExpr, which drove me to the following refactoring: * Move simpleOptExpr and simpleOptPgm from CoreSubst to a new module CoreOpt along with a few others (exprIsConApp_maybe, pushCoArg, etc) This eliminates a module loop altogether (delete CoreArity.hs-boot), and stops CoreSubst getting too huge. * Rename Simplify.matchOrConvertToJoinPoint to joinPointBinding_maybe Move it to the new CoreOpt Use it in simpleOptExpr as well as in Simplify * Define CoreArity.joinRhsArity and use it
* Make raiseIO# produce topResDavid Feuer2017-03-091-6/+4
| | | | | | | | | | | | | | | | | | Make `raiseIO#` produce `topRes` instead of `ExnRes`. `ExnRes` leads to demand analysis being too aggressive, IMO, allowing imprecise exceptions produced by `throw` to replace exceptions thrown by `throwIO` that would like to think of as precise. This fixes that, but is certanly much more conservative than we would ideally like. Let's see how bad it is. Fixes Trac #13380 Reviewers: austin, bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3301
* Fix strictness for catchSTMDavid Feuer2017-03-081-2/+9
| | | | | | | | | | | | | | * Fix demand analysist for `catchSTM#`. * Add more notes on demand analysis of `catch`-like functions. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3283
* Generate better fp abs for X86 and llvm with default cmm otherwiseDominic Steinitz2017-03-071-0/+4
| | | | | | | | | | | | | | | | | | | | | | | Currently we have this in libraries/base/GHC/Float.hs: ``` abs x | x == 0 = 0 -- handles (-0.0) | x > 0 = x | otherwise = negateFloat x ``` But 3-4 years ago it was noted that this was inefficient: https://mail.haskell.org/pipermail/libraries/2013-April/019690.html We can generate better code for X86 and llvm and for others generate some custom cmm code which is similar to what the compiler generates now. Reviewers: austin, simonmar, hvr, bgamari Reviewed By: bgamari Subscribers: dfeuer, thomie Differential Revision: https://phabricator.haskell.org/D3265
* primops: Add comment describing type of atomicModifyMutVar#Ben Gamari2017-03-061-3/+15
| | | | | | | | | | | | | | | | | This resolves #13130. It's not entirely clear to me why we don't use an unboxed tuple here but this is at least better than the status quo. [skip ci] Test Plan: Read it Reviewers: simonmar, austin, dfeuer Reviewed By: dfeuer Subscribers: dfeuer, rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3288
* Produce KindReps for common kinds in GHC.TypesBen Gamari2017-03-031-3/+20
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* Show: Add ShowS for ", "Ben Gamari2017-03-021-1/+2
| | | | | This is produced often enough in derived Show instances that it is likely worthwhile defining it once.
* Change catch# demand signatureDavid Feuer2017-03-011-1/+1
| | | | | | | | | | | | | | | | | | * Give `catch#` a lazy demand signature, to make it more honest. * Make `catchException` and `catchAny` force their arguments so they actually behave as advertised. * Use `catch` rather than `catchException` in `forkIO`, `forkOn`, and `forkOS` to avoid losing exceptions. Fixes #13330 Reviewers: rwbarton, simonpj, simonmar, bgamari, hvr, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3244
* Disable Typeable binding generation for unboxed sumsBen Gamari2017-02-181-2/+5
| | | | | These things are simply too expensive to generate at the moment. More work is needed here; see #13276 and #13261.
* Type-indexed TypeableBen Gamari2017-02-184-62/+170
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Generalize kind of the (->) tyconBen Gamari2017-02-181-13/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is generalizes the kind of `(->)`, as discussed in #11714. This involves a few things, * Generalizing the kind of `funTyCon`, adding two new `RuntimeRep` binders, ```lang=haskell (->) :: forall (r1 :: RuntimeRep) (r2 :: RuntimeRep) (a :: TYPE r1) (b :: TYPE r2). a -> b -> * ``` * Unsaturated applications of `(->)` are expressed as explicit `TyConApp`s * Saturated applications of `(->)` are expressed as `FunTy` as they are currently * Saturated applications of `(->)` are expressed by a new `FunCo` constructor in coercions * `splitTyConApp` needs to ensure that `FunTy`s are split to a `TyConApp` of `(->)` with the appropriate `RuntimeRep` arguments * Teach CoreLint to check that all saturated applications of `(->)` are represented with `FunTy` At the moment I assume that `Constraint ~ *`, which is an annoying source of complexity. This will be simplified once D3023 is resolved. Also, this introduces two known regressions, `tcfail181`, `T10403` ===================== Only shows the instance, instance Monad ((->) r) -- Defined in ‘GHC.Base’ in its error message when -fprint-potential-instances is used. This is because its instance head now mentions 'LiftedRep which is not in scope. I'm not entirely sure of the right way to fix this so I'm just accepting the new output for now. T5963 (Typeable) ================ T5963 is now broken since Data.Typeable.Internals.mkFunTy computes its fingerprint without the RuntimeRep variables that (->) expects. This will be fixed with the merge of D2010. Haddock performance =================== The `haddock.base` and `haddock.Cabal` tests regress in allocations by about 20%. This certainly hurts, but it's also not entirely unexpected: the size of every function type grows with this patch and Haddock has a lot of functions in its heap.
* Typos [ci skip]Gabor Greif2017-02-151-1/+1
|
* Implement HasField constraint solving and modify OverloadedLabelsAdam Gundry2017-02-141-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | This implements automatic constraint solving for the new HasField class and modifies the existing OverloadedLabels extension, as described in the GHC proposal (https://github.com/ghc-proposals/ghc-proposals/pull/6). Per the current form of the proposal, it does *not* currently introduce a separate `OverloadedRecordFields` extension. This replaces D1687. The users guide documentation still needs to be written, but I'll do that after the implementation is merged, in case there are further design changes. Test Plan: new and modified tests in overloadedrecflds Reviewers: simonpj, goldfire, dfeuer, bgamari, austin, hvr Reviewed By: bgamari Subscribers: maninalift, dfeuer, ysangkok, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D2708
* Tweaks and typos in manual, note refs, commentsGabor Greif2017-02-091-1/+1
|
* Fix documentation for setByteArray#Ben Gamari2017-02-081-1/+2
| | | | The documentation was previously unusably incomplete.
* Fix comment of `section "Exceptions"`Takenobu Tani2017-02-071-13/+12
| | | | | | | | | | | | | | | | | I changed comment from `{- .. -}` to `--`. Because Haddock comment for `section "Exceptions"` [1] was broken. [1]: https://downloads.haskell.org/~ghc/latest/docs/html/libraries/ghc-prim-0 .5.0.0/GHC-Prim.html Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3083
* Derive <$David Feuer2017-02-071-3/+7
| | | | | | | | | | | | | | | | Using the default definition of `<$` for derived `Functor` instance is very bad for recursive data types. Derive the definition instead. Fixes #13218 Reviewers: austin, bgamari, RyanGlScott Reviewed By: RyanGlScott Subscribers: RyanGlScott, thomie Differential Revision: https://phabricator.haskell.org/D3072
* Add liftA2 to Applicative classDavid Feuer2017-02-051-1/+2
| | | | | | | | | | | | | | | | * Make `liftA2` a method of `Applicative`. * Add explicit `liftA2` definitions to instances in `base`. * Add explicit invocations in `base`. Reviewers: ekmett, bgamari, RyanGlScott, austin, hvr Reviewed By: RyanGlScott Subscribers: ekmett, RyanGlScott, rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3031
* Introduce GHC.TypeNats module, change KnownNat evidence to be NaturalOleg Grenrus2017-02-011-4/+23
| | | | | | | | | | | | Reviewers: dfeuer, austin, hvr, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3024 GHC Trac Issues: #13181
* base: Derive Enum, Bounded for VecCount, VecElemBen Gamari2017-02-011-2/+2
| | | | | | | | | | | | Test Plan: Validate Reviewers: RyanGlScott, austin, hvr Reviewed By: RyanGlScott Subscribers: goldfire, RyanGlScott, thomie Differential Revision: https://phabricator.haskell.org/D3059
* Fix documentation NOTE about can_failVladislav Zavialov2017-02-011-1/+1
| | | | | In the note it is explained why it's fine to discard a can_fail primop, but the table erroneously says it's not fine.
* Mark reallyUnsafePtrEquality# as can_failDavid Feuer2017-01-311-0/+35
| | | | | | | | | | | | | | | | | As described in the note, floating `reallyUnsafePtrEquality#` out can make it much less precise. Marking it `can_fail` will prevent it from floating out, which I believe is particularly important in light of 5a9a1738023aeb742e537fb4a59c4aa8fecc1f8a, and should also help prevent let/app invariant failures as seen in #11444 and #13027. Reviewers: simonpj, austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2987 GHC Trac Issues: #13027, #11444
* Add pragCompleteDName to templateHaskellNamesRyan Scott2017-01-251-1/+1
| | | | | | | 95dc6dc070deac733d4a4a63a93e606a2e772a67 forgot to add `pragCompleteDName` to the list of `templateHaskellNames`, which caused a panic if you actually tried to splice a `COMPLETE` pragma using Template Haskell. This applies the easy fix and augments the regression test to check for this in the future.
* Template Haskell support for COMPLETE pragmasMatthew Pickering2017-01-261-41/+44
| | | | | | | | | | Reviewers: RyanGlScott, austin, goldfire, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2997 GHC Trac Issues: #13098
* Ensure that scrutinee constant folding wraps numbersSylvain Henry2017-01-231-31/+61
| | | | | | | | | | | | | | Test Plan: T13172 Reviewers: rwbarton, simonpj, austin, bgamari Reviewed By: simonpj, bgamari Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D3009 GHC Trac Issues: #13172
* Allow top-level string literals in Core (#8472)Takano Akio2017-01-201-18/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Add 'type family (m :: Symbol) <> (n :: Symbol)'Oleg Grenrus2017-01-201-0/+3
| | | | | | | | | | | Reviewers: dfeuer, austin, bgamari, hvr Subscribers: dfeuer, mpickering, RyanGlScott, ekmett, yav, lelf, simonpj, thomie Differential Revision: https://phabricator.haskell.org/D2632 GHC Trac Issues: #12162
* Update levity polymorphismRichard Eisenberg2017-01-195-166/+228
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
View Lorry Controller Status