- Dec 21, 2019
-
-
Ben Gamari authored
This is a very important branch yet it didn't have any prediction set. We predict the updated thunk to live in the young generation since this is how the original code predicted.
-
Ben Gamari authored
-
Ben Gamari authored
-
- Dec 20, 2019
-
-
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.
-
-
- Dec 19, 2019
-
-
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 a586b33f
-
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.
-
- Dec 18, 2019
-
-
Sylvain Henry authored
* 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)
-
- Dec 17, 2019
-
-
-
-
-
Due to #17557. Also accepting spurious performance change. Metric Decrease: T1969
-
This reverts commit 6cfc47ec.
-
-
`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
-
- Dec 16, 2019
-
-
Oleg Grenrus authored
Then one is freer to omit upper bounds, as we won't pick any new entries on Hackage while building hadrian itself.
-
Oleg Grenrus authored
Given that shake is far from "done" API wise, and is central component to the build system.
-
- Dec 12, 2019
-
-
This seems to have regressed builds using `--with-system-libffi` (#17520). This reverts commit 3ce18700.
-
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.
-
- Dec 11, 2019
-
-
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
-