| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
tested with `bash` and `zsh`.
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, `lookupBindGroupOcc`'s error message would recommend all
similar names in scope, regardless of whether they were type
constructors, data constructors, or functions, leading to the
confusion witnessed in #17593. This is easily fixed by only
recommending names in the same namespace, using the
`nameSpacesRelated` function.
Fixes #17593.
|
| |
|
|
|
|
|
|
|
|
| |
We can do a heap census with a non-profiling RTS. With a non-profiling
RTS we don't zero superfluous bytes of shrunk arrays hence a need to
handle the case specifically to avoid a crash.
Revert part of a586b33f8e8ad60b5c5ef3501c89e9b71794bbed
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In our codebase we have some code along the lines of
```
newStdout <- hDuplicate stdout
stderr `hDuplicateTo` stdout
```
to avoid stray `putStrLn`s from corrupting a protocol (LSP) that is
run over stdout.
On CI we have seen a bunch of issues where `dup2` returned `EBUSY` so
this fails with `ResourceExhausted` in Haskell.
I’ve spent some time looking at the docs for `dup2` and the code in
`base` and afaict the following race condition is being triggered
here:
1. The user calls `hDuplicateTo stderr stdout`.
2. `hDuplicateTo` calls `hClose_help stdout_`, this closes the file
handle for stdout.
3. The file handle for stdout is now free, so another thread
allocating a file might get stdout.
4. If `dup2` is called while `stdout` (now pointing to something
else) is half-open, it returns EBUSY.
I think there might actually be an even worse case where `dup2` is run
after FD 1 is fully open again. In that case, you will end up not just
redirecting the original stdout to stderr but also the whatever
resulted in that file handle being allocated.
As far as I can tell, `dup2` takes care of closing the file handle
itself so there is no reason to do this in `hDuplicateTo`. So this PR
replaces the call to `hClose_help` by the only part of `hClose_help`
that we actually care about, namely, `flushWriteBuffer`.
I tested this on our codebase fairly extensively and haven’t been able
to reproduce the issue with this patch.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Add 'dumpAction' hook to DynFlags.
It allows GHC API users to catch dumped intermediate codes and
information. The format of the dump (Core, Stg, raw text, etc.) is now
reported allowing easier automatic handling.
* Add 'traceAction' hook to DynFlags.
Some dumps go through the trace mechanism (for instance unfoldings that
have been considered for inlining). This is problematic because:
1) dumps aren't written into files even with -ddump-to-file on
2) dumps are written on stdout even with GHC API
3) in this specific case, dumping depends on unsafe globally stored
DynFlags which is bad for GHC API users
We introduce 'traceAction' hook which allows GHC API to catch those
traces and to avoid using globally stored DynFlags.
* Avoid dumping empty logs via dumpAction/traceAction (but still write
empty files to keep the existing behavior)
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Due to #17557.
Also accepting spurious performance change.
Metric Decrease:
T1969
|
|
|
|
| |
This reverts commit 6cfc47ec8a478e1751cb3e7338954da1853c3996.
|
| |
|
|
|
|
|
| |
`T5435_v_asm_a`, `T5435_v_asm_b`, and `T5435_v_gcc` all fail on ARMv7.
See #17559.
|
|
|
|
|
|
|
|
|
|
| |
Previously it would hackily look at the flavour name to determine
whether LLVM was used to build stage2 ghc. However, this didn't work at
all with Hadrian and would miss cases like ARM where we use the LLVM
backend by default.
See #16087 for the motivation for why ghc_built_by_llvm is needed at
all. This should catch one of the ARMv7 failures described in #17555.
|
|
|
|
| |
Due to #17558.
|
|
|
|
| |
Due to #17557.
|
|
|
|
| |
Due to #17556.
|
|
|
|
| |
Due to #17555.
|
|
|
|
|
| |
Due to #17554. It's very surprising that this only occurs on ARMv7 but
this is the only place I've seen this failure thusfar.
|
| |
|
|
|
|
| |
Also eliminate some redundancy.
|
| |
|
| |
|
|
|
|
|
| |
The python release shipped with deb8 (3.3) is too old for our testsuite
driver.
|
| |
|
|
|
|
| |
Variable interpolation in gitlab-ci.yml apparently doesn't work. Sigh.
|
|
|
|
|
|
| |
Close #17583.
Test case: typecheck/should_fail/T17563
|
|
|
|
|
|
|
|
|
|
|
| |
As described in #17291, we'd like to separate coercions and expressions
in a more robust fashion.
This is a small step in this direction.
- `mkLocalId` now panicks on a covar.
Calls where this was not the case were changed to `mkLocalIdOrCoVar`.
- Don't use "OrCoVar" functions in places where we know the type is
not a coercion.
|
|
|
|
| |
As suggested in #17291
|
|
|
|
|
| |
Then one is freer to omit upper bounds, as we won't pick
any new entries on Hackage while building hadrian itself.
|
|
|
|
|
| |
Given that shake is far from "done" API wise,
and is central component to the build system.
|
|
|
|
|
|
|
| |
This seems to have regressed builds using `--with-system-libffi`
(#17520).
This reverts commit 3ce18700f80a12c48a029b49c6201ad2410071bb.
|
|
|
|
| |
This sacrifices some precision in favor of improving parallelism.
|
| |
|
|
|
|
|
|
|
| |
The previous implementation was extremely complicated, seemingly to
allow the local and CI namespaces to be searched incrementally. However,
it's quite unclear why this is needed and moreover the implementation
seems to have had quadratic runtime cost in the search depth(!).
|
|
|
|
|
| |
I only added it into --simple-output and ghc-pkg check output;
there are probably other places where it can be adopted.
|
|
|
|
|
|
|
|
|
|
|
| |
Silly users sometimes try to use visible dependent quantification
and polymorphic recursion without a CUSK or SAK. This causes
unexpected errors. So we now adjust expectations with a bit
of helpful messaging.
Closes #17541 and closes #17131.
test cases: dependent/should_fail/T{17541{,b},17131}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Separate word and string hash tables on the type level, and do not store
the hashing function. Thus when a different hash function is desire it
is provided upon accessing the table. This is worst case the same as
before the change, and in the majority of cases is better. Also mark the
functions for aggressive inlining to improve performance. {F1686506}
Reviewers: bgamari, erikd, simonmar
Subscribers: rwbarton, thomie, carter
GHC Trac Issues: #13165
Differential Revision: https://phabricator.haskell.org/D4889
|
|
|
|
| |
This script was previously a whitespace nightmare.
|
| |
|
|
|
|
| |
This way it is next to the other fixed-sized ones.
|
|
|
|
|
| |
This matches the organization of the fixed-sized ones, and keeps each
Int* next to its corresponding Word*.
|
|
|
|
|
| |
I'm not sure how this was omitted from the list of supported
architectures.
|
|
|
|
| |
Fixes #17547.
|
|
|
|
| |
Allowing it to be easily used locally.
|
|
|
|
| |
Allowing it to be easily used locally.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We deliberately avoid defining a magical `Unit%` class, for reasons
that I have expounded upon in the newly added
`Note [Ignore unary constraint tuples]` in `TcHsType`. However, a
sneaky user could try to insert `Unit%` into their program by way of
Template Haskell, leading to the interface-file error observed
in #17511. To avoid this, any time we encounter a unary constraint
tuple during typechecking, we drop the surrounding constraint tuple
application. This is safe to do since `Unit% a` and `a` would be
semantically equivalent (unlike other forms of unary tuples).
Fixes #17511.
|
|
|
|
|
| |
The old flag, `-xn`, was quite cryptic. Here we add `--nonmoving-gc` in
addition.
|
| |
|