| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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
|
| | |
|
| |
|
|
|
| |
No changes to code; no changes to theory. Just better
explanation.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Close #17672.
By scratching our heads quite hard, we realized that
we should never kick out Given/Nominal equalities. This
commit tweaks the kick-out conditions accordingly.
See also Note [K4] which describes what is going on.
This does not fix a known misbehavior, but it should be
a small improvement in both practice (kicking out is bad,
and we now do less of it) and theory (a Given/Nominal should
behave just like a filled-in metavariable, which has no notion
of kicking out).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Kick out condition K2b really only makes sense for
inerts with a type variable on the left. This updates
the commentary and the code to skip this check for
inerts with type families on the left.
Also cleans up some commentary around solver invariants
and adds Note [K2b].
Close #19042.
test case: typecheck/should_compile/T19042
|
| | |
|
| | |
|
| |
|
|
| |
Also includes small unrelated type fix
|
| |
|
|
|
| |
The test max memory usage improves dramatically with the fixes to
memory usage in demand analyser from #15455
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There used to be some cases were kinds were not generalised properly
before being printed in GHCi. This seems to have changed in the past so
now it's uncessary to tidy before printing out the test case.
```
> :set -XPolyKinds
> data A x y
> :k A
k1 -> k2 -> A
```
This tidying was causing issues with an attempt to increase sharing by
making `mkTyConApp` (see !4762)
|
| |
|
|
|
|
|
|
|
|
|
| |
The approach taking in this patch is that the tcl_bndrs in TcLclEnv are
zonked and tidied eagerly, so that work can be shared across multiple
calls to `relevant_bindings`.
To test this patch I tried without the `keepThisHole` filter and the
test finished quickly.
Fixes #14766
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
In commit f3c23939 T18623 is disabled for aarch64.
The limit seems to be too low for powerpc64le, too. This could be
because tables next to code is not supported and our code generator
produces larger code on PowerPC.
|
| |
|
|
|
|
|
| |
This allows us to use the unsafe shifts in non-debug builds for performance.
For older versions of base we instead export Data.Bits
See also #19618
|
| |
|
|
|
| |
Metric Decrease:
T16577
|
| | |
|
| |
|
|
|
|
|
| |
This commit moves the error-related functions in `GHC.Iface.Load` into
a brand new module called `GHC.Iface.Errors`. This will avoid boot files
and circular dependencies in the context of #18516, in the
pretty-printing modules.
|
| |
|
|
|
|
|
|
|
|
| |
Previously, associated type family instances would incorrectly claim to
implicitly quantify over type variables bound by the instance head in the
`HsOuterImplicit`s that `rnFamEqn` returned. This is fixed by using
`filterInScopeM` to filter out any type variables that the instance head
binds.
Fixes #19649.
|
| |
|
|
| |
Fixes #11545
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This avoids a big spike in memory usage during demand analysis.
Part of fixing #15455
-------------------------
Metric Decrease:
T18698a
T18698b
T9233
T9675
T9961
-------------------------
|
| |
|
|
|
|
| |
It seems that these places were supposed to be forced anyway but the
forcing has no effect because the result was immediately placed in a
lazy box.
|
| |
|
|
|
|
| |
In the particular case of `DmdEnv`, not applying this function strictly
meant 500MB of thunks were accumulated before the values were forced at
the end of demand analysis.
|
| |
|
|
|
|
| |
This can lead to a classic thunk build-up in a TcRef
Fixes #19596
|
| | |
|
| | |
|
| |
|
|
| |
Related to #15455
|
| |
|
|
|
| |
And though partially applied foldl' is now again inlined, #4301 has not
resurfaced, and appears to be resolved.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Dynamic-by-default was a mechanism to automatically select the -dynamic
way for some targets.
It was implemented in a convoluted way: it was defined as a flavour
option, hence it couldn't be passed as a global settings (which are
produced by `configure` before considering flavours), so a build system
rule was used to pass -DDYNAMIC_BY_DEFAULT to the C compiler so that
deriveConstants could infer it.
* Make build system has it disabled for 8 years (951e28c0625ece7e0db6ac9d4a1e61e2737b10de)
* It has never been implemented in Hadrian
* Last time someone tried to enable it 1 year ago it didn't work (!2436)
* Having this as a global constant impedes making GHC multi-target (see !5427)
This commit fully removes support for dynamic-by-default. If someone
wants to reimplement something like this, it would probably need to move
the logic in the compiler.
(Doing this would probably need some refactoring of the way the compiler
handles DynFlags: DynFlags are used to store and to pass enabled ways to
many parts of the compiler. It can be set by command-line flags, GHC
API, global settings. In multi-target GHC, we will use DynFlags to load
the target platform and its constants: but at this point with the
current DynFlags implementation we can't easily update the existing
DynFlags with target-specific options such as dynamic-by-default without
overriding ways previously set by the user.)
|
| |
|
|
| |
Workaround for #19624
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The patch
commit c43c981705ec33da92a9ce91eb90f2ecf00be9fe
Author: Simon Peyton Jones <simonpj@microsoft.com>
Date: Fri Oct 23 16:15:51 2009 +0000
Fix Trac #3591: very tricky specialiser bug
fixed a nasty specialisation bug /for DFuns/. Eight years
later, this patch
commit 2b74bd9d8b4c6b20f3e8d9ada12e7db645cc3c19
Author: Simon Peyton Jones <simonpj@microsoft.com>
Date: Wed Jun 7 12:03:51 2017 +0100
Stop the specialiser generating loopy code
extended it to work for /imported/ DFuns. But in the process
we lost the fact that it was needed only for DFuns! As a result
we started silently losing useful specialisation for non-DFuns.
But there was no regression test to spot the lossage.
Then, nearly four years later, Andreas filed #19599, which showed
the lossage in high relief. This patch restores the DFun test,
and adds Note [Avoiding loops (non-DFuns)] to explain why.
This is undoubtedly a very tricky corner of the specialiser,
and one where I would love to have a more solid argument, even a
paper! But meanwhile I think this fixes the lost specialisations
without introducing any new loops.
I have two regression tests, T19599 and T19599a, so I hope we'll
know if we lose them again in the future.
Vanishingly small effect on nofib.
A couple of compile-time benchmarks improve
T9872a(normal) ghc/alloc 1660559328.0 1643827784.0 -1.0% GOOD
T9872c(normal) ghc/alloc 1691359152.0 1672879384.0 -1.1% GOOD
Many others wiggled around a bit.
Metric Decrease:
T9872a
T9872c
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This reverts commit 0cbdba2768d84a0f6832ae5cf9ea1e98efd739da.
|
| |
|
|
|
|
|
| |
Previously we used this non-portable function unconditionally, breaking
FreeBSD.
Fixes #19637.
|
| |
|
|
|
|
|
| |
As noted by #19589, `stack` is not stateful and therefore must be passed
`--nix` on every invocation. Do so.
Fixes #19589.
|
| |
|
|
|
|
| |
Not only does this eliminate some code duplication but we also
add a maximum core count to HLint's command-line, hopefully avoiding
issue #19600.
|
| | |
|
| | |
|
| |
|
|
| |
See #17018.
|
| |
|
|
|
|
| |
It is incorrectly displayed in hackage as:
`m1 <*> m2 = m1 >>= (x1 -> m2 >>= (x2 -> return (x1 x2)))`
which isn't correct Haskell
|
| |
|
|
|
|
|
| |
In version 0.12.2.0 of vector when used with GHC-9.0 we
rebox values from storeable mutable vectors.
This should catch such a change in the future.
|
| | |
|
| | |
|
| |
|
|
| |
and not just the name on the binary on the `$PATH`.
|
| |
|
|
|
|
|
|
|
|
| |
Fixes #19616.
This commit changes the `GHC.Driver.Errors.handleFlagWarnings` function
to rely on the newly introduced `DiagnosticReason`. This allows us to
correctly pretty-print the flags which triggered some warnings and in
turn remove the cruft around this function (like the extra filtering
and the `shouldPrintWarning` function.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit introduces a new `Severity` type constructor called
`SevIgnore`, which can be used to classify diagnostic messages which are
not meant to be displayed to the user, for example suppressed warnings.
This extra constructor allows us to get rid of a bunch of redundant
checks when emitting diagnostics, typically in the form of the pattern:
```
when (optM Opt_XXX) $
addDiagnosticTc (WarningWithFlag Opt_XXX) ...
```
Fair warning! Not all checks should be omitted/skipped, as evaluating some data
structures used to produce a diagnostic might still be expensive (e.g.
zonking, etc). Therefore, a case-by-case analysis must be conducted when
deciding if a check can be removed or not.
Last but not least, we remove the unnecessary `CmdLine.WarnReason` type, which is now
redundant with `DiagnosticReason`.
|
| |
|
|
|
| |
These changes made it slightly easier for me to work out what was going
on in this test. I've also fixed a typo in the comments.
|
| |
|
|
|
| |
In the common case where the list of ticks is empty, building a thunk
just applies 'reverse' to '[]' which is quite wasteful.
|
