| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Fixes #17848, a regression introduced by 6e2d9ee2.
|
| |
|
|
|
|
| |
Closes #17706.
|
|
|
|
|
|
|
|
| |
This reverts commit 8cf646d36b02b8ea1c289cb52781c9171853b514.
The flag was removed by 16d643cf.
[ci skip]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These manifested in the integer-simple job.
Metric Decrease:
T12227
T5549
T14936
T4830
Conversions
T5237
T8766
T4801
T10359
Metric Increase:
T12234
T6048
T3294
T14683
T3064
T9872b
T9872c
T783
T5837
T10678
T14697
T5631
T9203
T13719
T12707
T13056
T9630
T10547
T9872d
T1969
WWRec
T10370
T5321FD
haddock.Cabal
T5642
T9872a
T15263
T12425
MultiLayerModules
T5205
T9233
T13379
haddock.base
T9020
T13035
T12150
T9961
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
The original reason this was disabled should be fixed by the previous
commit.
This reverts commit 1c1b63d63efe8b0f789aa7d5b87cfac3edd213eb.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GHC should make calls using process jobs when calling out to GCC and LD.
The reason is these use the exec () family of posix functions. Window's
process model doesn't allow replacement of processes so this is emulated
by creating a new process and immediately exiting the old one. Because
of this when using normal Windows wait functions you would return even
without the child process having finished. In this case if you are
depending on data from the child you will enter a race condition.
The usual fix for this is to use process jobs and wait for the
termination of all children that have ever been spawn by the process you
called. But also waiting for the freeing of all resources.
|
|
|
|
|
|
|
| |
Folds in the second part of Phyx's Windows process exit fixes [1],
hopefully finally resolving issue #17480.
[1] https://github.com/haskell/process/pull/160
|
| |
|
|
|
|
|
|
| |
The fact that `exec` isn't POSIX compliant means that things can break
in arbitrarily bad ways. Sometimes things happen to work correctly but
sadly this isn't always the case.
|
| |
|
| |
|
|
|
|
| |
Due to the resistance of #17736 to resolution.
|
|
|
|
| |
This will help track down #17035.
|
|
|
|
| |
Apparently it isn't supported by some slightly older Python versions.
|
|
|
|
|
|
| |
Previously opsys would take any string. This meant it was very easy for
a typo to silently render the predicate ineffective. Fix this by
checking the given operating system name against a list of known values.
|
|
|
|
|
| |
Due to #16799. There was previously an attempt to mark it as broken but
the `opsys` name was incorrect.
|
|
|
|
| |
I have no idea how this worked previously. Different Python version?
|
|
|
|
| |
Fixes #17748.
|
| |
|
| |
|
| |
|
|
|
|
| |
The check for the "v" prefix is redundant.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we did this only on Darwin due to #17414. However, even on
other platforms >2GB writes are on shaky ground. POSIX explicitly says
that the result is implementation-specified and Linux will write at most
0x7ffff000, even on 64-bit platforms. Moreover, getting the sign
of the syscall result correct is tricky, as demonstrated by the fact
that T17414 currently fails on FreeBSD.
For simplicity we now just uniformly clamp to 0x7ffff000 on all
platforms.
|
|
|
|
|
| |
FreeBSD cc throws a warning if we pass -pthread without actually using
any pthread symbols.
|
|
|
|
| |
In BSD grep this flag only affects directory recursion.
|
| |
|
| |
|
|
|
|
|
| |
Some sed implementations (e.g. FreeBSD) refuse to operate in-place on
symlinks.
|
|
|
|
| |
-L is only needed during linking.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This moves nearly all of the CI logic to .gitlab/ci.sh. This improves
things in a number of ways:
* it's harder for inconsistencies to arise between architectures
* it's easier to share logic between architectures
* on Windows, it's easier to ensure that all CI steps are executed from
within a properly initialized mingw session.
While in town I also add a FreeBSD build job and update the Windows job
to use the gitlab-runner PowerShell executor, since cmd.exe will be
deprecated soon (fixing #17699).
|
| |
|
| |
|
|
|
|
|
|
|
| |
It seems that Sphinx produces the ghc-flags.txt in
doc/users_guide/_build rather than pdfRoot. We could copy ghc-flags.txt
into pdfRoot (like happens naturally in the HTML case) but the benefit
is pretty small. Let's just only check the HTML case.
|
|
|
|
| |
Documentation only. Fixes #17827
|
| |
|
| |
|
|
|
| |
(cherry picked from commit a5e0f376821ca882880b03b07b451aa574e289ec)
|
| |
|
| |
|
|
|
|
|
| |
When Hadrian failed to build, the script would pick a previously built
Hadrian (if available) instead of failing.
|
| |
|
|
|
|
| |
This flag is deemed not useful.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We now always show "forall {a}. T" for inferred variables,
previously this was controlled by -fprint-explicit-foralls.
This implements part 1 of https://github.com/ghc-proposals/ghc-proposals/pull/179.
Part of GHC ticket #16320.
Furthermore, when printing a levity restriction error, we now display
the HsWrap of the expression. This lets users see the full elaboration with
-fprint-typechecker-elaboration (see also #17670)
|