| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Throw a slightly more informative error on failure. Motivated by the
errors seen in !2160.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we would push stack-carried return values to the new stack on
a stack overflow. While the precise reasoning for this barrier is
unfortunately lost to history, in hindsight I suspect it was prompted by
a missing barrier elsewhere (that has been since fixed).
Moreover, there the redundant barrier is actively harmful: the stack may
contain non-pointer values; blindly pushing these to the mark queue will
result in a crash. This is precisely what happened in the `stack003`
test. However, because of a (now fixed) deficiency in the test this
crash did not trigger on amd64.
|
|
|
|
|
|
| |
Previously the returned tuple seemed to fit in registers on amd64. This
meant that non-moving collector bug would cause the test to fail on i386
yet not amd64.
|
|
|
|
|
|
|
|
|
| |
Previously we would reset the pointer pointing to the object to be
marked to the beginning of the block when marking a large object. This
did no harm on 64-bit but on 32-bit it broke, e.g. `arr020`, since we
align pinned ByteArray allocations such that the payload is 8
byte-aligned. This means that the object might not begin at the
beginning of the block.,
|
|
|
|
|
| |
The previous representation needlessly limited the array length to
16-bits on 32-bit platforms.
|
|
|
|
|
|
| |
We were using TAG_BITS instead of TAG_MASK. This happened to work on
64-bit platforms where TAG_BITS==3 since we only use tag values 0 and
3. However, this broken on 32-bit platforms where TAG_BITS==2.
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we used INFO_PTR_TO_STRUCT instead of
THUNK_INFO_PTR_TO_STRUCT when looking at a thunk. These two happen to be
equivalent on 64-bit architectures due to alignment considerations
however they are different on 32-bit platforms. This lead to #17487.
To fix this we also employ a small optimization: there is only one thunk
of type WHITEHOLE (namely stg_WHITEHOLE_info). Consequently, we can just
use a plain pointer comparison instead of testing against info->type.
|
|
|
|
| |
This broke the Windows build.
|
|
|
|
| |
Should finally fix #17255.
|
|
|
|
|
| |
As reported in #8173 in some environments package lists can get quite
long, so we use more efficient ordNub instead of nub on package lists.
|
|
|
|
|
|
|
|
|
|
|
| |
If using a pthread instead of a timer signal is more reliable, and
has no known drawbacks, then FreeBSD is also capable of supporting
this mode of operation (tested on FreeBSD 12 with GHC 8.8.1, but
no reason why it would not also work on FreeBSD 11 or GHC 8.6).
Proposed by Kevin Zhang in:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241849
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`GHC.Prim.seq` previously had the rather plain type:
seq :: forall a b. a -> b -> b
However, it also had a special typing rule to applications
where `b` is not of kind `Type`.
Issue #17440 noted that levity polymorphism allows us to rather give
it the more precise type:
seq :: forall (r :: RuntimeRep) a (b :: TYPE r). a -> b -> b
This allows us to remove the special typing rule that we previously
required to allow applications on unlifted arguments. T9404 contains a
non-Type application of `seq` which should verify that this works as
expected.
Closes #17440.
|
|
|
|
|
| |
The need for this note vanished in
eae703aa60f41fd232be5478e196b661839ec3de.
|
|
|
|
|
| |
Metric Decrease:
T14683
|
|
|
|
|
|
| |
It is typical for $TMP to be a small tmpfson Linux. This test will fail
in such cases since we must create a file larger than the filesystem.
See #17459.
|
| |
|
| |
|
| |
|
|
|
|
| |
The previous commit hasn't made it to master yet.
|
|
|
|
| |
Adopts the language suggested by @JakobBruenker.
|
| |
|
|
|
|
|
|
| |
I previously increased the size of the acceptance window from 2% to 5%
but this still isn't enough. Regardless, measuring bytes allocated
should be sufficient to catch any regressions.
|
|
|
|
| |
Bumps haddock submodule.
|
|
|
|
|
| |
We ran it against the .git directory despite the fact that the linter
wants to be run against the repository.
|
| |
|
|
|
|
| |
This statistic is rather unstable. Hopefully fixes #17475.
|
| |
|
| |
|
|
|
|
|
| |
This is an attempt to mitigate #17480 by ensuring that a functional version of
the process library is available before attempting the build.
|
| |
|
|
|
|
|
| |
Metric Increase:
T4801
|
|
|
|
| |
Haskeline now depends upon exceptions. See #16752.
|
|
|
|
|
|
|
|
| |
HscRecomp users only need the ModLocation of the module being compiled,
so only pass that to users instead of the entire ModSummary
Metric Decrease:
T4801
|
|
|
|
|
|
|
|
|
| |
Issue #17461 was occurring because the `Outputable` instance for
standalone kind signatures was simply calling `ppr` on the name in
the kind signature, which does not add parentheses to infix names.
The solution is simple: use `pprPrefixOcc` instead.
Fixes #17461.
|
| |
|
|
|
|
|
|
| |
As noted in #17458, QuantifiedConstraints and UndecideableInstances
could previously be used to write programs which can loop at runtime.
This was fixed in !1870.
|
|
|
|
| |
By only using 'export' from within bash commands.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously an import cycle between Type and TyCoRep meant that several
functions in TyCoRep ended up SOURCE import coreView. This is quite
unfortunate as coreView is intended to be fused into a larger pattern
match and not incur an extra call.
Fix this with a bit of restructuring:
* Move the functions in `TyCoRep` which depend upon things in `Type`
into `Type`
* Fold contents of `Kind` into `Type` and turn `Kind` into a simple
wrapper re-exporting kind-ish things from `Type`
* Clean up the redundant imports that popped up as a result
Closes #17441.
Metric Decrease:
T4334
|
|
|
|
| |
[ci skip]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We instead want to collect the runtime stats (with collect_stats, instead of
collect_compiler_stats).
This should fix a number of perf tests failures we have been seeing, where
we suddenly started measuring metrics we didn't intend to measure, which
tend to fall outside of the acceptance window.
Metric Decrease:
lazy-bs-alloc
T3586
Metric Increase:
space_leak_001
T4801
T5835
T12791
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The corresponding commit might introduce a regression on a perf test, in which
case we certainly want to record it. The testsuite might also fail because
of a test unrelated to performance, in which case we want to record that the
perf test results were good.
Either way, we likely want to record them under all circumstances but
we don't without this patch.
Metric Decrease:
T3586
Metric Increase:
lazy-bs-alloc
|
| |
|
|
|
|
|
| |
This addresses #17456 and also fixes the --metrics-file argument that Hadrian
passes to the testsuite driver.
|
|
|
|
|
|
| |
Previously we would call check_stats to check the runtime metrics even
if the test definition hadn't requested it. This would result in an
error since the .stats file doesn't exist.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As suggested in #17387; this helps reduce the variance in our residency
sampling.
Metric Increase:
T10370
T3586
lazy-bs-alloc
Metric Decrease 'compile_time/peak_megabytes_allocated':
T1969
Metric Decrease 'runtime/bytes allocated':
space_leak_001
Metric Increase 'compile_time/bytes allocated':
T1969
Metric Increase 'runtime/peak_megabytes_allocated':
space_leak_001
Metric Decrease:
T3064
T9675
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, we checked all imported type family equations
for injectivity. This is very silly. Now, we check only
for conflicts.
Before I could even imagine doing the fix, I needed to untangle
several functions that were (in my opinion) overly complicated.
It's still not quite as perfect as I'd like, but it's good enough
for now.
Test case: typecheck/should_compile/T17405
|
| |
|
| |
|
| |
|