summaryrefslogtreecommitdiff
path: root/libraries
Commit message (Collapse)AuthorAgeFilesLines
...
* Redesign withDict (formerly magicDict)Ryan Scott2021-04-298-28/+94
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This gives a more precise type signature to `magicDict` as proposed in #16646. In addition, this replaces the constant-folding rule for `magicDict` in `GHC.Core.Opt.ConstantFold` with a special case in the desugarer in `GHC.HsToCore.Expr.dsHsWrapped`. I have also renamed `magicDict` to `withDict` in light of the discussion in https://mail.haskell.org/pipermail/ghc-devs/2021-April/019833.html. All of this has the following benefits: * `withDict` is now more type safe than before. Moreover, if a user applies `withDict` at an incorrect type, the special-casing in `dsHsWrapped` will now throw an error message indicating what the user did incorrectly. * `withDict` can now work with classes that have multiple type arguments, such as `Typeable @k a`. This means that `Data.Typeable.Internal.withTypeable` can now be implemented in terms of `withDict`. * Since the special-casing for `withDict` no longer needs to match on the structure of the expression passed as an argument to `withDict`, it no longer cares about the presence or absence of `Tick`s. In effect, this obsoletes the fix for #19667. The new `T16646` test case demonstrates the new version of `withDict` in action, both in terms of `base` functions defined in terms of `withDict` as well as in terms of functions from the `reflection` and `singletons` libraries. The `T16646Fail` test case demonstrates the error message that GHC throws when `withDict` is applied incorrectly. This fixes #16646. By adding more tests for `withDict`, this also fixes #19673 as a side effect.
* Fix inlining of division wrappersSylvain Henry2021-04-291-0/+18
|
* Make divModInt# branchlessSylvain Henry2021-04-292-24/+69
|
* Allow divInt#/modInt# to inline (#18067)Sylvain Henry2021-04-291-2/+2
|
* Refactor modInt# to make it branchlessSylvain Henry2021-04-291-7/+59
|
* Refactor divInt# to make it branchless (#18067, #19636)Sylvain Henry2021-04-291-9/+68
|
* Add documentation for GHC.Exts.sortWithiori tsu2021-04-271-0/+5
| | | | | | sortWith has the same type definition as `Data.List.sortOn` (eg: `Ord b => (a -> b) -> [a] -> [a]`). Nonetheless, they behave differently, sortOn being more efficient. This merge request add documentation to reflect on this differences
* Eliminate unsafeEqualityProof in CorePrepSimon Peyton Jones2021-04-261-23/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The main idea here is to avoid treating * case e of {} * case unsafeEqualityProof of UnsafeRefl co -> blah specially in CoreToStg. Instead, nail them in CorePrep, by converting case e of {} ==> e |> unsafe-co case unsafeEqualityProof of UnsafeRefl cv -> blah ==> blah[unsafe-co/cv] in GHC.Core.Prep. Now expressions that we want to treat as trivial really are trivial. We can get rid of cpExprIsTrivial. And we fix #19700. A downside is that, at least under unsafeEqualityProof, we substitute in types and coercions, which is more work. But a big advantage is that it's all very simple and principled: CorePrep really gets rid of the unsafeCoerce stuff, as it does empty case, runRW#, lazyId etc. I've updated the overview in GHC.Core.Prep, and added Note [Unsafe coercions] in GHC.Core.Prep Note [Implementing unsafeCoerce] in base:Unsafe.Coerce We get 3% fewer bytes allocated when compiling perf/compiler/T5631, which uses a lot of unsafeCoerces. (It's a happy-generated parser.) Metric Decrease: T5631
* Add Eq1 and Ord1 Fixed instancesOleg Grenrus2021-04-262-1/+11
|
* Enable tables next to code for riscv64Andreas Schwab2021-04-191-0/+9
| | | | | This requires adding another rewrite to the mangler, to avoid generating PLT entries.
* Use correct precedence in Complex's Read1/Show1 instancesRyan Scott2021-04-184-3/+50
| | | | Fixes #19719.
* Data.List strictness optimisations for maximumBy and minimumByHécate Moonlight2021-04-141-14/+21
| | | | follow-up from !4675
* Report actual port in libiserv:Remote.Slave.startSlaveFacundo Domínguez2021-04-101-1/+2
| | | | | | This allows to start iserv by passing port 0 to startSlave, which in turns allows to get an available port when no port is known to be free a priori.
* Implement list `fold` and `foldMap` via mconcatKoz Ross2021-04-106-0/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - This allows specialized mconcat implementations an opportunity to combine elements efficiently in a single pass. - Inline the default implementation of `mconcat`, this may result in list fusion. - In Monoids with strict `mappend`, implement `mconcat` as a strict left fold: * And (FiniteBits) * Ior (FiniteBits) * Xor (FiniteBits) * Iff (FiniteBits) * Max (Ord) * Min (Ord) * Sum (Num) * Product (Num) * (a -> m) (Monoid m) - Delegate mconcat for WrappedMonoid to the underlying monoid. Resolves: #17123 Per the discussion in !4890, we expect some stat changes: * T17123(normal) run/alloc 403143160.0 4954736.0 -98.8% GOOD This is the expected improvement in `fold` for a long list of `Text` elements. * T13056(optasm) ghc/alloc 381013328.0 447700520.0 +17.5% BAD Here there's an extra simplifier run as a result of the new methods of the Foldable instance for List. It looks benign. The test is a micro benchmark that compiles just the derived foldable instances for a pair of structures, a cost of this magnitude is not expected to extend to more realistic programs. * T9198(normal) ghc/alloc 504661992.0 541334168.0 +7.3% BAD This test regressed from 8.10 and 9.0 back to exponential blowup. This metric also fluctuates, for reasons not yet clear. The issue here is the exponetial blowup, not this MR. Metric Decrease: T17123 Metric Increase: T9198 T13056
* Bignum: add BigNat Eq/Ord instances (#19647)Sylvain Henry2021-04-091-0/+16
|
* Change foldl' to inline when partially applied (#19534)James Foster2021-04-072-17/+66
| | | | | And though partially applied foldl' is now again inlined, #4301 has not resurfaced, and appears to be resolved.
* Bignum: remove unused extra filesSylvain Henry2021-04-051-2/+0
|
* Bignum: fix invalid hs-boot declaration (#19638)Sylvain Henry2021-04-051-1/+1
|
* Fixes Monad's associativity docsŁukasz Gołębiewski2021-04-051-1/+1
| | | | | | It is incorrectly displayed in hackage as: `m1 <*> m2 = m1 >>= (x1 -> m2 >>= (x2 -> return (x1 x2)))` which isn't correct Haskell
* Address review feedback on chiralityViktor Dukhovni2021-04-011-11/+45
| | | | Also added nested foldr example for `concat`.
* Chiral foldable caveatsViktor Dukhovni2021-04-011-3/+37
|
* libiserv: Add descriptionBen Gamari2021-04-011-2/+2
|
* ghc-boot: Use cabal-version: 3.0Ben Gamari2021-04-011-2/+3
|
* ghc-bignum: Add missing source files to cabal fileBen Gamari2021-04-011-0/+2
|
* Data.List specialization to []Oleg Grenrus2021-04-0117-1609/+1360
| | | | | | | - Remove GHC.OldList - Remove Data.OldList - compat-unqualified-imports is no-op - update haddock submodule
* Add -Wcompat to hadrianOleg Grenrus2021-03-312-0/+0
| | | | Update submodules haskeline and hpc
* Additionally export asum from Control.ApplicativeOleg Grenrus2021-03-302-1/+4
| | | | Fixes #19575
* Allocate Adjustors and mark them readable in two stepsMoritz Angermann2021-03-293-1/+20
| | | | | | | | | This drops allocateExec for darwin, and replaces it with a alloc, write, mark executable strategy instead. This prevents us from trying to allocate an executable range and then write to it, which X^W will prohibit on darwin. This will *only* work if we can use mmap.
* Make RULES more robust in GHC.FloatSimon Peyton Jones2021-03-281-75/+155
| | | | | | | | | | | | | The RULES that use hand-written specialised code for overloaded class methods like floor, ceiling, truncate etc were fragile to certain transformations. This patch makes them robust. See #19582. It's all described in Note [Rules for overloaded class methods]. No test case because currently we don't do the transformation (floating out over-saturated applications) that makes this patch have an effect. But we may so so in future, and this patch makes the RULES much more robust.
* Bump Win32 to 2.13.0.0GHC GitLab CI2021-03-264-0/+0
| | | | Bumps Win32 submodule.
* Add compiler linting to CIHécate2021-03-251-1/+0
| | | | | This commit adds the `lint:compiler` Hadrian target to the CI runner. It does also fixes hints in the compiler/ and libraries/base/ codebases.
* base: Use mutableByteArrayContentsBen Gamari2021-03-223-13/+11
|
* Bump template-haskell version to 2.18.0.0wip/T19083Ryan Scott2021-03-204-2/+2
| | | | | | | This requires bumping the `exceptions` and `text` submodules to bring in commits that bump their respective upper version bounds on `template-haskell`. Fixes #19083.
* Move miscategorized items in template-haskell changelogRyan Scott2021-03-201-6/+6
|
* Clean up TBDs in changelogBen Gamari2021-03-201-1/+7
| | | | (cherry picked from commit 4f334120c8e9cc4aefcbf11d99f169f648af9fde)
* Fix fake import in GHC.Exception.Type boot moduleSylvain Henry2021-03-205-23/+22
| | | | | | | | | It seems like I imported "GHC.Types ()" thinking that it would transitively import GHC.Num.Integer when I wrote that module; but it doesn't. This led to build failures. See https://mail.haskell.org/pipermail/ghc-devs/2021-March/019641.html
* Add more boundary checks for `rem` and `mod`John Ericson2021-03-201-18/+44
| | | | | | | | | | | | | | | | | It's quite backend-dependent whether we will actually handle that case right, so let's just always do this as a precaution. In particular, once we replace the native primops used here with the new sized primops, the 16-bit ones on x86 will begin to use 16-bit sized instructions where they didn't before. Though I'm not sure of any arch which has 8-bit scalar instructions, I also did those for consistency. Plus, there are *vector* 8-bit ops in the wild, so if we ever got into autovectorization or something maybe it's prudent to put this here as a reminder not to forget about catching overflows. Progress towards #19026
* Generate GHCi bytecode from STG instead of Core and support unboxedLuite Stegeman2021-03-201-1/+1
| | | | | | tuples and sums. fixes #1257
* [skip ci] Fix 'Ord' documentation inconsistencyGaël Deest2021-03-201-4/+4
| | | | | | | | | | | | | | | | | | | Current documentation for the `Ord` typeclass is inconsistent. It simultaneously mentions that: > The 'Ord' class is used for totally ordered datatypes. And: > The Haskell Report defines no laws for 'Ord'. However, '<=' is > customarily expected to implement a non-strict partial order […] The Haskell report (both 98 and 2010 versions) mentions total ordering, which implicitly does define laws. Moreover, `compare :: Ord a => a -> a -> Ordering` and `data Ordering = LT | EQ | GT` imply that the order is indeed total (there is no way to say that two elements are not comparable). This MR fixes the Haddock comment, and adds a comparability law to the list of suggested properties.
* Built-in type families: CharToNat, NatToChar (#19535)Vladislav Zavialov2021-03-172-0/+16
| | | | | Co-authored-by: Daniel Rogozin <daniel.rogozin@serokell.io> Co-authored-by: Rinat Stryungis <rinat.stryungis@serokell.io>
* fromInteger :: Integer -> {Float,Double} now always round to nearest evenARATA Mizuki2021-03-174-21/+56
| | | | | | | | integerToFloat# and integerToDouble# were moved from ghc-bignum to base. GHC.Integer.floatFromInteger and doubleFromInteger were removed. Fixes #15926, #17231, #17782
* [ci] Skip test's on windows that often fail in CI.wip/angerman/stable-windowsMoritz Angermann2021-03-161-1/+2
|
* Implement the UnliftedDatatypes extensionSebastian Graf2021-03-142-1/+3
| | | | | | | | | | | | | | | | | | GHC Proposal: 0265-unlifted-datatypes.rst Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/265 Issues: https://gitlab.haskell.org/ghc/ghc/-/issues/19523 Implementation Details: Note [Implementation of UnliftedDatatypes] This patch introduces the `UnliftedDatatypes` extension. When this extension is enabled, GHC relaxes the restrictions around what result kinds are allowed in data declarations. This allows data types for which an unlifted or levity-polymorphic result kind is inferred. The most significant changes are in `GHC.Tc.TyCl`, where `Note [Implementation of UnliftedDatatypes]` describes the details of the implementation. Fixes #19523.
* Update win32 submoduleTamar Christina2021-03-121-0/+0
|
* testsuite: Update Win32 test output for GHC2021GHC GitLab CI2021-03-111-0/+0
| | | | Fixes the Windows CI jobs. Requires update of the Win32 submodule.
* Ignore breakpoint for a specified number of iterations. (#19157)Roland Senn2021-03-103-52/+53
| | | | | | | | | | | | | | | | * Implement new debugger command `:ignore` to set an `ignore count` for a specified breakpoint. * Allow new optional parameter on `:continue` command to set an `ignore count` for the current breakpoint. * In the Interpreter replace the current `Word8` BreakArray with an `Int` array. * Change semantics of values in `BreakArray` to: n < 0 : Breakpoint is disabled. n == 0 : Breakpoint is enabled. n > 0 : Breakpoint is enabled, but ignore next `n` iterations. * Rewrite `:enable`/`:disable` processing as a special case of `:ignore`. * Remove references to `BreakArray` from `ghc/UI.hs`.
* Use GHC2021 as default languageJoachim Breitner2021-03-106-16/+26
|
* template-haskell: Add putDoc, getDoc, withDecDoc and friendsLuke Lau2021-03-108-1/+237
| | | | | | | | | | | | | | | | | | | | | | | This adds two new methods to the Quasi class, putDoc and getDoc. They allow Haddock documentation to be added to declarations, module headers, function arguments and class/type family instances, as well as looked up. It works by building up a map of names to attach pieces of documentation to, which are then added in the extractDocs function in GHC.HsToCore.Docs. However because these template haskell names need to be resolved to GHC names at the time they are added, putDoc cannot directly add documentation to declarations that are currently being spliced. To remedy this, withDecDoc/withDecsDoc wraps the operation with addModFinalizer, and provides a more ergonomic interface for doing so. Similarly, the funD_doc, dataD_doc etc. combinators provide a more ergonomic interface for documenting functions and their arguments simultaneously. This also changes ArgDocMap to use an IntMap rather than an Map Int, for efficiency. Part of the work towards #5467
* Bump bytestring submodule to 0.11.1.0Ben Gamari2021-03-109-3/+3
|
* rts: Gradually return retained memory to the OSMatthew Pickering2021-03-101-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Related to #19381 #19359 #14702 After a spike in memory usage we have been conservative about returning allocated blocks to the OS in case we are still allocating a lot and would end up just reallocating them. The result of this was that up to 4 * live_bytes of blocks would be retained once they were allocated even if memory usage ended up a lot lower. For a heap of size ~1.5G, this would result in OS memory reporting 6G which is both misleading and worrying for users. In long-lived server applications this results in consistent high memory usage when the live data size is much more reasonable (for example ghcide) Therefore we have a new (2021) strategy which starts by retaining up to 4 * live_bytes of blocks before gradually returning uneeded memory back to the OS on subsequent major GCs which are NOT caused by a heap overflow. Each major GC which is NOT caused by heap overflow increases the consec_idle_gcs counter and the amount of memory which is retained is inversely proportional to this number. By default the excess memory retained is oldGenFactor (controlled by -F) / 2 ^ (consec_idle_gcs * returnDecayFactor) On a major GC caused by a heap overflow, the `consec_idle_gcs` variable is reset to 0 (as we could continue to allocate more, so retaining all the memory might make sense). Therefore setting bigger values for `-Fd` makes the rate at which memory is returned slower. Smaller values make it get returned faster. Setting `-Fd0` disables the memory return completely, which is the behaviour of older GHC versions. The default is `-Fd4` which results in the following scaling: > mapM print [(x, 1/ (2**(x / 4))) | x <- [1 :: Double ..20]] (1.0,0.8408964152537146) (2.0,0.7071067811865475) (3.0,0.5946035575013605) (4.0,0.5) (5.0,0.4204482076268573) (6.0,0.35355339059327373) (7.0,0.29730177875068026) (8.0,0.25) (9.0,0.21022410381342865) (10.0,0.17677669529663687) (11.0,0.14865088937534013) (12.0,0.125) (13.0,0.10511205190671433) (14.0,8.838834764831843e-2) (15.0,7.432544468767006e-2) (16.0,6.25e-2) (17.0,5.255602595335716e-2) (18.0,4.4194173824159216e-2) (19.0,3.716272234383503e-2) (20.0,3.125e-2) So after 13 consecutive GCs only 0.1 of the maximum memory used will be retained. Further to this decay factor, the amount of memory we attempt to retain is also influenced by the GC strategy for the oldest generation. If we are using a copying strategy then we will need at least 2 * live_bytes for copying to take place, so we always keep that much. If using compacting or nonmoving then we need a lower number, so we just retain at least `1.2 * live_bytes` for some protection. In future we might want to make this behaviour more aggressive, some relevant literature is > Ulan Degenbaev, Jochen Eisinger, Manfred Ernst, Ross McIlroy, and Hannes Payer. 2016. Idle time garbage collection scheduling. SIGPLAN Not. 51, 6 (June 2016), 570–583. DOI:https://doi.org/10.1145/2980983.2908106 which describes the "memory reducer" in the V8 javascript engine which on an idle collection immediately returns as much memory as possible.
View Lorry Controller Status