summaryrefslogtreecommitdiff
path: root/compiler/prelude
Commit message (Collapse)AuthorAgeFilesLines
...
* Fix over-eager constant folding in bitIntegerSimon Peyton Jones2018-03-221-16/+36
| | | | | | | | | | | The RULE for bitInteger was trying to constant-fold bitInteger 9223372036854775807# which meant constructing a gigantic Integer at compile time. Very bad idea! Easily fixed. Fixes Trac #14959, #14962.
* Fix seq# case of exprOkForSpeculationSimon Peyton Jones2018-03-202-8/+51
| | | | | | | | | This subtle patch fixes Trac #5129 (again; comment:20 and following). I took the opportunity to document seq# properly; see Note [seq# magic] in PrelRules, and Note [seq# and expr_ok] in CoreUtils.
* Improve accuracy of get/setAllocationCounterBen Gamari2018-03-191-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: get/setAllocationCounter didn't take into account allocations in the current block. This was known at the time, but it turns out to be important to have more accuracy when using these in a fine-grained way. Test Plan: New unit test to test incrementally larger allocaitons. Before I got results like this: ``` +0 +0 +0 +0 +0 +4096 +0 +0 +0 +0 +0 +4064 +0 +0 +4088 +4056 +0 +0 +0 +4088 +4096 +4056 +4096 ``` Notice how the results aren't always monotonically increasing. After this patch: ``` +344 +416 +488 +560 +632 +704 +776 +848 +920 +992 +1064 +1136 +1208 +1280 +1352 +1424 +1496 +1568 +1640 +1712 +1784 +1856 +1928 +2000 +2072 +2144 ``` Reviewers: hvr, erikd, simonmar, jrtc27, trommler Reviewed By: simonmar Subscribers: trommler, jrtc27, rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4363
* Document missing dataToTag# . tagToEnum# ruleDavid Feuer2018-02-191-0/+13
| | | | | | | | | | | | | | | | | Explain why we don't have a rule to optimize `dataToTag# (tagToEnum# x)` to `x`. [skip ci] Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14282 Differential Revision: https://phabricator.haskell.org/D4375
* myThreadId# is trivial; make it an inline primopSimon Marlow2018-02-181-1/+0
| | | | | | | | | | | | | | | The pattern `threadCapability =<< myThreadId` is used a lot in code that uses `hs_try_putmvar`, I want to make it cheaper. Test Plan: validate Reviewers: bgamari, erikd Reviewed By: bgamari Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4381
* Fix utterly bogus TagToEnum rule in caseRulesSimon Peyton Jones2018-02-071-13/+26
| | | | | | | | | | | | | | | | In prelRules we had: tx_con_tte :: DynFlags -> AltCon -> AltCon tx_con_tte _ DEFAULT = DEFAULT tx_con_tte dflags (DataAlt dc) | tag == 0 = DEFAULT -- See Note [caseRules for tagToEnum] | otherwise = LitAlt (mkMachInt dflags (toInteger tag)) The tag==0 case is totally wrong, and led directly to Trac #14768. See "Beware" in Note [caseRules for tagToEnum] (in the patch). Easily fixed, though!
* Don't apply dataToTag's caseRules for data familiesRyan Scott2018-02-031-2/+10
| | | | | | | | | | | | | | | | | | | | | Commit 193664d42dbceadaa1e4689dfa17ff1cf5a405a0 added a special caseRule for `dataToTag`, but this transformation completely broke when `dataToTag` was applied to somewith with a type headed by a data family, leading to #14680. For now at least, the simplest solution is to simply not apply this transformation when the type is headed by a data family. Test Plan: make test TEST=T14680 Reviewers: simonpj, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14680 Differential Revision: https://phabricator.haskell.org/D4371
* Add new mbmi and mbmi2 compiler flagsJohn Ky2018-01-211-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | This adds support for the bit deposit and extraction operations provided by the BMI and BMI2 instruction set extensions on modern amd64 machines. Implement x86 code generator for pdep and pext. Properly initialise bmiVersion field. pdep and pext test cases Fix pattern match for pdep and pext instructions Fix build of pdep and pext code for 32-bit architectures Test Plan: Validate Reviewers: austin, simonmar, bgamari, angerman Reviewed By: bgamari Subscribers: trommler, carter, angerman, thomie, rwbarton, newhoggy GHC Trac Issues: #14206 Differential Revision: https://phabricator.haskell.org/D4236
* Revert "Improve accuracy of get/setAllocationCounter"Ben Gamari2018-01-181-14/+0
| | | | This reverts commit a1a689dda48113f3735834350fb562bb1927a633.
* Fix hash in haddock of ghc-prim.HE, Tao2018-01-151-1/+1
| | | | | | | | | | | | Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14653 Differential Revision: https://phabricator.haskell.org/D4305
* Kill off irrefutable pattern errorsDavid Feuer2018-01-151-2/+1
| | | | | | | | | | | | | | | | | Distinguishing between "refutable" and "irrefutable" patterns (as described by the Haskell Report) in incomplete pattern errors was more confusing than helpful. Remove references to irrefutable patterns. Reviewers: hvr, bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie, carter GHC Trac Issues: #14569 Differential Revision: https://phabricator.haskell.org/D4261
* Lift constructor tag allocation out of a loopBartosz Nitka2018-01-101-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this change, for each constructor that we want to allocate a tag for we would traverse a list of all the constructors in a datatype to determine which tag a constructor should get. This is obviously quadratic and for datatypes with 10k constructors it actually makes a big difference. This change implements the plan outlined by @simonpj in https://mail.haskell.org/pipermail/ghc-devs/2017-October/014974.html which is basically about using a map and constructing it outside the loop. One place where things got a bit awkward was TysWiredIn.hs, it would have been possible to just assign the tags by hand, but that seemed error-prone to me, so I decided to go through a map there as well. Test Plan: ./validate On a file with 10k constructors Before: 8,130,522,344 bytes allocated in the heap Total time 3.682s ( 3.920s elapsed) After: 4,133,478,744 bytes allocated in the heap Total time 2.509s ( 2.750s elapsed) Reviewers: simonpj, bgamari Reviewed By: simonpj Subscribers: goldfire, rwbarton, thomie, simonmar, carter, simonpj GHC Trac Issues: #14657 Differential Revision: https://phabricator.haskell.org/D4289
* Improve accuracy of get/setAllocationCounterSimon Marlow2018-01-081-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: get/setAllocationCounter didn't take into account allocations in the current block. This was known at the time, but it turns out to be important to have more accuracy when using these in a fine-grained way. Test Plan: New unit test to test incrementally larger allocaitons. Before I got results like this: ``` +0 +0 +0 +0 +0 +4096 +0 +0 +0 +0 +0 +4064 +0 +0 +4088 +4056 +0 +0 +0 +4088 +4096 +4056 +4096 ``` Notice how the results aren't always monotonically increasing. After this patch: ``` +344 +416 +488 +560 +632 +704 +776 +848 +920 +992 +1064 +1136 +1208 +1280 +1352 +1424 +1496 +1568 +1640 +1712 +1784 +1856 +1928 +2000 +2072 +2144 ``` Reviewers: niteria, bgamari, hvr, erikd Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4288
* Cache the number of data cons in DataTyCon and SumTyConBartosz Nitka2018-01-041-35/+30
| | | | | | | | | | | | | | | | This is a follow-up after faf60e85 - Make tagForCon non-linear. On the mailing list @simonpj suggested to solve the linear behavior by caching the sizes. Test Plan: ./validate Reviewers: simonpj, simonmar, bgamari, austin Reviewed By: simonpj Subscribers: carter, goldfire, rwbarton, thomie, simonpj Differential Revision: https://phabricator.haskell.org/D4131
* Rename HEq_sc and Coercible_sc to heq_sel and coercible_selMatthew Pickering2018-01-021-2/+2
| | | | | | | | | | | | | | | | | These functions are record selectors. To the unfamiliar, when inspecting core, they looked like data constructors as they started with an upper case letter. We rename them so that it is more clear that firstly they are functions and secondly that they are selectors. Reviewers: bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4280
* Typos in comments [ci skip]Gabor Greif2017-12-281-1/+1
|
* Rmove a call to mkStatePrimTySimon Peyton Jones2017-12-191-3/+3
| | | | | This is a tiny refactoring that removes one of the calls to mkStatePrimTy, in service to Trac #14596
* Stop runRW# being magicSimon Peyton Jones2017-12-191-1/+3
| | | | | | | | Triggered by thinking about Trac #14596, I found that runRW# does not need to be a "magic" wired-in Id, now that we have levity polymorphism. This patch stops it being wired-in.
* Get rid of some stuttering in comments and docsGabor Greif2017-12-191-1/+1
|
* Tidy up of wired-in namesSimon Peyton Jones2017-12-131-4/+5
| | | | | | | | | | | | Two things here: * While debugging Trac #14561 I found it hard to understand ghcPrimIds and magicIds in MkId. This patch adds more structure and comments. * I also discovered that ($) no longer needs to be a wiredInId because we now have levity polymorphism. So I took dollarId out of MkId; and gave it a levity-polymorphic type in GHC.Base
* template-haskell: Rip out FamFlavourBen Gamari2017-12-041-12/+0
| | | | | This was scheduled to happen for 8.2, it looks like it will actually happen in 8.4.
* Cache TypeRep kinds aggressivelyDavid Feuer2017-12-011-10/+15
| | | | | | | | | | | | | | | | | | | Cache `TypeRep k` in each `TrApp` or `TrTyCon` constructor of `TypeRep (a :: k)`. This makes `typeRepKind` cheap. With this change, we won't need any special effort to deserialize typereps efficiently. The downside, of course, is that we make `TypeRep`s slightly larger. Reviewers: austin, hvr, bgamari, simonpj Reviewed By: bgamari, simonpj Subscribers: carter, simonpj, rwbarton, thomie GHC Trac Issues: #14254 Differential Revision: https://phabricator.haskell.org/D4085
* Add trace injectionDavid Feuer2017-12-011-2/+10
| | | | | | | | | | | | | | Add support for injecting runtime calls to `trace` in `DsM`. This allows the desugarer to add compile-time information to a runtime trace. Reviewers: austin, hvr, bgamari Reviewed By: bgamari Subscribers: carter, thomie, rwbarton Differential Revision: https://phabricator.haskell.org/D4162
* Revert "Add new mbmi and mbmi2 compiler flags"Ben Gamari2017-11-221-22/+0
| | | | | | This broke the 32-bit build. This reverts commit f5dc8ccc29429d0a1d011f62b6b430f6ae50290c.
* base: Document GHC.Stack.CCS internalsBen Gamari2017-11-211-1/+1
| | | | | | | | Reviewers: hvr Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D4204
* Add new mbmi and mbmi2 compiler flagsJohn Ky2017-11-151-0/+22
| | | | | | | | | | | | | | | | | This adds support for the bit deposit and extraction operations provided by the BMI and BMI2 instruction set extensions on modern amd64 machines. Test Plan: Validate Reviewers: austin, simonmar, bgamari, hvr, goldfire, erikd Reviewed By: bgamari Subscribers: goldfire, erikd, trommler, newhoggy, rwbarton, thomie GHC Trac Issues: #14206 Differential Revision: https://phabricator.haskell.org/D4063
* Imrpove comments about equality typesSimon Peyton Jones2017-11-082-12/+15
|
* Turn `compareByteArrays#` out-of-line primop into inline primopalexbiehl2017-10-291-1/+0
| | | | | | | | | | | | Depends on D4090 Reviewers: austin, bgamari, erikd, simonmar, alexbiehl Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D4091
* Factor out readField (#14364)Tobias Dammers2017-10-251-0/+4
| | | | | | | | | | | | | | | | | | | Improves compiler performance of deriving Read instances, as suggested in the issue. Additionally, we introduce `readSymField`, a companion to `readField` that parses symbol-type fields (where the field name is a symbol, e.g. `(#)`, rather than an alphanumeric identifier. The decision between these two functions is made a compile time, because we already know which one we need based on the field name. Reviewers: austin, hvr, bgamari, RyanGlScott Reviewed By: bgamari Subscribers: RyanGlScott, rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D4108
* Implement new `compareByteArrays#` primopHerbert Valerio Riedel2017-10-161-3/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The new primop compareByteArrays# :: ByteArray# -> Int# {- offset -} -> ByteArray# -> Int# {- offset -} -> Int# {- length -} -> Int# allows to compare the subrange of the first `ByteArray#` to the (same-length) subrange of the second `ByteArray#` and returns a value less than, equal to, or greater than zero if the range is found, respectively, to be byte-wise lexicographically less than, to match, or be greater than the second range. Under the hood, the new primop is implemented in terms of the standard ISO C `memcmp(3)` function. It is currently an out-of-line primop but work is underway to optimise this into an inline primop for a future follow-up Differential (see D4091). This primop has applications in packages like `text`, `text-short`, `bytestring`, `text-containers`, `primitive`, etc. which currently have to incur the overhead of an ordinary FFI call to directly or indirectly invoke `memcmp(3)` as well has having to deal with some `unsafePerformIO`-variant. While at it, this also improves the documentation for the existing `copyByteArray#` primitive which has a non-trivial type-signature that significantly benefits from a more explicit description of its arguments. Reviewed By: bgamari Differential Revision: https://phabricator.haskell.org/D4090
* Fix typoPeter Trommler2017-10-161-1/+1
|
* Implement Div, Mod, and Log for type-level nats.Iavor Diatchki2017-10-031-15/+21
| | | | | | | | | | Reviewers: austin, hvr, bgamari Reviewed By: bgamari Subscribers: RyanGlScott, dfeuer, adamgundry, rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D4002
* Track the order of user-written tyvars in DataConRyan Scott2017-10-031-7/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After typechecking a data constructor's type signature, its type variables are partitioned into two distinct groups: the universally quantified type variables and the existentially quantified type variables. Then, when prompted for the type of the data constructor, GHC gives this: ```lang=haskell MkT :: forall <univs> <exis>. (...) ``` For H98-style datatypes, this is a fine thing to do. But for GADTs, this can sometimes produce undesired results with respect to `TypeApplications`. For instance, consider this datatype: ```lang=haskell data T a where MkT :: forall b a. b -> T a ``` Here, the user clearly intended to have `b` be available for visible type application before `a`. That is, the user would expect `MkT @Int @Char` to be of type `Int -> T Char`, //not// `Char -> T Int`. But alas, up until now that was not how GHC operated—regardless of the order in which the user actually wrote the tyvars, GHC would give `MkT` the type: ```lang=haskell MkT :: forall a b. b -> T a ``` Since `a` is universal and `b` is existential. This makes predicting what order to use for `TypeApplications` quite annoying, as demonstrated in #11721 and #13848. This patch cures the problem by tracking more carefully the order in which a user writes type variables in data constructor type signatures, either explicitly (with a `forall`) or implicitly (without a `forall`, in which case the order is inferred). This is accomplished by adding a new field `dcUserTyVars` to `DataCon`, which is a subset of `dcUnivTyVars` and `dcExTyVars` that is permuted to the order in which the user wrote them. For more details, refer to `Note [DataCon user type variables]` in `DataCon.hs`. An interesting consequence of this design is that more data constructors require wrappers. This is because the workers always expect the first arguments to be the universal tyvars followed by the existential tyvars, so when the user writes the tyvars in a different order, a wrapper type is needed to swizzle the tyvars around to match the order that the worker expects. For more details, refer to `Note [Data con wrappers and GADT syntax]` in `MkId.hs`. Test Plan: ./validate Reviewers: austin, goldfire, bgamari, simonpj Reviewed By: goldfire, simonpj Subscribers: ezyang, goldfire, rwbarton, thomie GHC Trac Issues: #11721, #13848 Differential Revision: https://phabricator.haskell.org/D3687
* Comments onlySimon Peyton Jones2017-10-031-8/+9
|
* TypofixesGabor Greif2017-09-271-2/+2
|
* PrelRules: Handle Int left shifts of more than word-size bitsBen Gamari2017-09-261-8/+14
| | | | | | | | | | | | | | | This should result in zero. Failing to realize this caused us to try to constant-fold via the normal path, resulting in #14272. Test Plan: Validate with coming tests Reviewers: austin, simonpj Subscribers: simonpj, rwbarton, thomie, hvr GHC Trac Issues: #14272 Differential Revision: https://phabricator.haskell.org/D4025
* primops: Add some notes regarding the meaning of the "type" fieldBen Gamari2017-09-261-0/+8
| | | | | | The overloading of "monadic" definitely deserved some explanation. [skip ci]
* Omit Typeable from the "naturally coherent" listSimon Peyton Jones2017-09-261-16/+15
| | | | | | | | | | | | | | | In doing something else (Trac #14218) I tripped over the definition of "naturally coherent" classes. This patch - Cocuments properly what that means - Removes Typeable from the list, because now we know what it meams, Typeable clearly doesn't belong. No regressions. (Actually the term "naturally coherent" seems a bit off. More like "invertible" or something. But I left it.)
* Add NOINLINE pragma to builtinRulesBen Gamari2017-09-251-0/+3
| | | | | | | | | | | | | | | | | | | As mentioned in #14275, GHC will otherwise decide to produce unfoldings for this rather large binding, making recompilation more expensive than necessary. Since inlining is almost certainly not fruitful mark it as NOINLINE. [skip ci] Test Plan: Validate Reviewers: austin Subscribers: rwbarton, thomie GHC Trac Issues: #14275 Differential Revision: https://phabricator.haskell.org/D4023
* Deal with large extra-contraints wildcardsSimon Peyton Jones2017-09-251-3/+4
| | | | | | | | | | | | | | | For reasons explained in TcHsType Note [Extra-constraint holes in partial type signatures], if we had f :: (_) => blahs and the '_' was filled in by more than a 62-tuple of contraints, GHC crashed. The same Note explains the hacky solution I have adopted to evade this. Maybe there is some better way, but I couldn't see one that didn't involve a great deal of work. And the problem is a very narrow one! If the hack bites us we'll need to think again.
* compiler: introduce custom "GhcPrelude" PreludeHerbert Valerio Riedel2017-09-1911-0/+21
| | | | | | | | | | | | | | | | | | This switches the compiler/ component to get compiled with -XNoImplicitPrelude and a `import GhcPrelude` is inserted in all modules. This is motivated by the upcoming "Prelude" re-export of `Semigroup((<>))` which would cause lots of name clashes in every modulewhich imports also `Outputable` Reviewers: austin, goldfire, bgamari, alanz, simonmar Reviewed By: bgamari Subscribers: goldfire, rwbarton, thomie, mpickering, bgamari Differential Revision: https://phabricator.haskell.org/D3989
* Model divergence of retry# as ThrowsExn, not DivergesBen Gamari2017-09-131-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The demand signature of the retry# primop previously had a Diverges result. However, this caused the demand analyser to conclude that a program of the shape, catchRetry# (... >> retry#) would diverge. Of course, this is plainly wrong; catchRetry#'s sole reason to exist is to "catch" the "exception" thrown by retry#. While catchRetry#'s demand signature correctly had the ExnStr flag set on its first argument, indicating that it should catch divergence, the logic associated with this flag doesn't apply to Diverges results. This resulted in #14171. The solution here is to treat the divergence of retry# as an exception. Namely, give it a result type of ThrowsExn rather than Diverges. Updates stm submodule for tests. Test Plan: Validate with T14171 Reviewers: simonpj, austin Subscribers: rwbarton, thomie GHC Trac Issues: #14171, #8091 Differential Revision: https://phabricator.haskell.org/D3919
* Clarify seq documentationSibi Prabakaran2017-09-131-2/+3
| | | | | | | | | | | | | | | Improves the documentation by specifying that the first argument in seq function is evaluated to WHNF. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: harendra, rwbarton, thomie GHC Trac Issues: #14213 Differential Revision: https://phabricator.haskell.org/D3945
* Canonicalise MonoidFail instances in GHCHerbert Valerio Riedel2017-09-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | IOW, code compiles -Wnoncanonical-monoidfail-instances clean now This is easy now since we require GHC 8.0/base-4.9 or later for bootstrapping. Note that we can easily enable `MonadFail` via default-extensions: MonadFailDesugaring in compiler/ghc.cabal.in which currently would point out that NatM doesn't have a proper `fail` method, even though failable patterns are made use of: compiler/nativeGen/SPARC/CodeGen.hs:425:25: error: * No instance for (Control.Monad.Fail.MonadFail NatM) arising from a do statement with the failable pattern ‘(dyn_c, [dyn_r])’
* Remove now redundant CPPHerbert Valerio Riedel2017-09-092-6/+0
| | | | Resulting from requiring to boot with GHC 8.0 or later
* Make Semigroup a superclass of Monoid (re #14191)Herbert Valerio Riedel2017-09-071-5/+3
| | | | | | | | | | | | | | | | | | | Unfortunately, this requires introducing a couple of .hs-boot files to break up import cycles (mostly to provide class & typenames in order to be able to write type signatures). This does not yet re-export `(<>)` from Prelude (while the class-name `Semigroup` is reexported); that will happen in a future commit. Test Plan: local ./validate passed Reviewers: ekmett, austin, bgamari, erikd, RyanGlScott Reviewed By: ekmett, RyanGlScott GHC Trac Issues: #14191 Differential Revision: https://phabricator.haskell.org/D3927
* Fix order of PrelRuleBen Gamari2017-09-011-1/+1
| | | | | | | | | | | | Test Plan: Added testcase in D3905. Reviewers: austin Subscribers: angerman, rwbarton, thomie GHC Trac Issues: #14178 Differential Revision: https://phabricator.haskell.org/D3904
* Add debugPprTypeSimon Peyton Jones2017-08-311-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | We pretty-print a type by converting it to an IfaceType and pretty-printing that. But (a) that's a bit indirect, and (b) delibrately loses information about (e.g.) the kind on the /occurrences/ of a type variable So this patch implements debugPprType, which pretty prints the type directly, with no fancy formatting. It's just used for debugging. I took the opportunity to refactor the debug-pretty-printing machinery a little. In particular, define these functions and use them: ifPprDeubug :: SDoc -> SDOc -> SDoc -- Says what to do with and without -dppr-debug whenPprDebug :: SDoc -> SDoc -- Says what to do with -dppr-debug; without is empty getPprDebug :: (Bool -> SDoc) -> SDoc getPprDebug used to be called sdocPprDebugWith whenPprDebug used to be called ifPprDebug So a lot of files get touched in a very mechanical way
* Small refactor of getRuntimeRepSimon Peyton Jones2017-08-291-2/+2
| | | | | | | | | Instead of using a string argument, use HasDebugCallStack. (Oddly, some functions were using both!) Plus, use getRuntimeRep rather than getRuntimeRep_maybe when if the caller panics on Nothing. Less code, and a better debug stack.
* Drop GHC 7.10 compatibilityRyan Scott2017-08-011-18/+5
| | | | | | | | | | | | | | | | GHC 8.2.1 is out, so now GHC's support window only extends back to GHC 8.0. This means we can delete gobs of code that was only used for GHC 7.10 support. Hooray! Test Plan: ./validate Reviewers: hvr, bgamari, austin, goldfire, simonmar Reviewed By: bgamari Subscribers: Phyx, rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3781
View Lorry Controller Status