| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Fixes #19631.
|
|
|
|
|
|
|
|
|
|
|
| |
We think the compiler is ready, so we can do this for all over the 8-,
16-, and 32-bit boxed types.
We are holding off on doing all the primops at once so things are easier
to investigate.
Metric Decrease:
T12545
|
| |
|
|
|
|
|
|
|
| |
With a quick flavour I get:
before T12545(normal) ghc/alloc 8628109152
after T12545(normal) ghc/alloc 8559741088
|
|
|
|
|
| |
Like !5572, this is switching over a portion of the primops which seems
safe to use.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
This requires adding another rewrite to the mangler, to avoid generating
PLT entries.
|
|
|
|
| |
Fixes #19719.
|
|
|
|
| |
follow-up from !4675
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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
|
| |
|
|
|
|
|
| |
And though partially applied foldl' is now again inlined, #4301 has not
resurfaced, and appears to be resolved.
|
| |
|
| |
|
|
|
|
|
|
| |
It is incorrectly displayed in hackage as:
`m1 <*> m2 = m1 >>= (x1 -> m2 >>= (x2 -> return (x1 x2)))`
which isn't correct Haskell
|
|
|
|
| |
Also added nested foldr example for `concat`.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
- Remove GHC.OldList
- Remove Data.OldList
- compat-unqualified-imports is no-op
- update haddock submodule
|
|
|
|
| |
Update submodules haskeline and hpc
|
|
|
|
| |
Fixes #19575
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Bumps Win32 submodule.
|
|
|
|
|
| |
This commit adds the `lint:compiler` Hadrian target to the CI runner.
It does also fixes hints in the compiler/ and libraries/base/ codebases.
|
| |
|
|
|
|
|
|
|
| |
This requires bumping the `exceptions` and `text` submodules to bring in
commits that bump their respective upper version bounds on `template-haskell`.
Fixes #19083.
|
| |
|
|
|
|
| |
(cherry picked from commit 4f334120c8e9cc4aefcbf11d99f169f648af9fde)
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
tuples and sums.
fixes #1257
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Co-authored-by: Daniel Rogozin <daniel.rogozin@serokell.io>
Co-authored-by: Rinat Stryungis <rinat.stryungis@serokell.io>
|
|
|
|
|
|
|
|
| |
integerToFloat# and integerToDouble# were moved from ghc-bignum to base.
GHC.Integer.floatFromInteger and doubleFromInteger were removed.
Fixes #15926, #17231, #17782
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Fixes the Windows CI jobs. Requires update of the Win32 submodule.
|