- Feb 01, 2024
-
-
This is a semantics-preserving refactoring.
-
-
-
-
-
In hand-written Cmm it can sometimes be necessary to atomically load from memory deep within an expression (e.g. see the `CHECK_GC` macro). This MachOp provides a convenient way to do so without breaking the expression into multiple statements.
-
Resolves #24394
-
- Jan 31, 2024
-
-
Simon Peyton Jones authored
This fixes #24370 by making decomposeRuleLhs undertand dictionary /functions/ as well as plain /dictionaries/
-
-
-
A test *сс018* is attached (not sure about the naming convention though). Note that without the fix, the test fails with the *dodgy-foreign-imports* warning passed to stderr. The warning disappears after the fix. GHC shouldn't warn on imports of natural function pointers from C by value (which is feasible with CApiFFI), such as ```haskell foreign import capi "cc018.h value f" f :: FunPtr (Int -> IO ()) ``` where ```c void (*f)(int); ``` See a related real-world use-case [here](https://gitlab.com/daniel-casanueva/pcre-light/-/merge_requests/17). There, GHC warns on import of C function pointer `pcre_free`.
-
- Jan 29, 2024
- Jan 26, 2024
-
-
-
-
Matt Walker authoredAdd tests for semicolon separated where clauses
-
- Jan 25, 2024
-
-
-
The GHC.Linker module is empty and unused, other than as a hack for the make build system. We can remove it now that make is long gone; the note is moved to GHC.Linker.Loader instead.
-
- Jan 24, 2024
-
-
-
We were emitting the wrong instructions for fused multiply-add operations on LLVM: - the instruction name is "llvm.fma.f32" or "llvm.fma.f64", not "fmadd" - LLVM does not support other instructions such as "fmsub"; instead we implement these by flipping signs of some arguments - the instruction is an LLVM intrinsic, which requires handling it like a normal function call instead of a machine instruction Fixes #24223 -
Otherwise spurious "Killed: 9" messages to stderr may cause the test to fail. Fixes #24361.
-
Bump hpc to 0.7.0.1 Bump hpc-bin to commit d1780eb2
-
They don't make it through readFile' without explicitly setting the encoding. See ghc/ghc#17755
-
The wasm backend didn't properly make use of all Cmm global registers due to #24347. Now that it is fixed, this patch re-enables full register mapping for wasm32, and we can now generate smaller & faster wasm modules that doesn't always spill arguments onto the stack. Fixes #22460 #24152.
-
This commit fixes incorrectly built genapply when cross compiling (#24347) by nuking all fragile CPP logic in it from the orbit. All target-specific info are now read from DerivedConstants.h at runtime, see added note for details. Also removes a legacy Makefile and adds haskell language server support for genapply.
-
-
-
- Jan 20, 2024
-
-
-
Just a small refactoring to avoid redundantly specifying the same strings in two different places.
-
-
Also remove the hence unused testsuite option `--test-package-db`. Fixes #24342
-
- Jan 19, 2024
-
-
Go through compiler/ sources, and remove all BangPatterns (and other GHC2021 enabled extensions in these files).
-
Fixes #24171.
-
- Jan 18, 2024
-
-
These bugs are all described in #24335 It's not easy to provoke the bug, hence no test case.
-
-
- Jan 17, 2024
-
-
Cheng Shao authored
On posix platforms, when performing read/write on FDs, we check the nonblocking flag first. For FDs without this flag (e.g. stdout), we call fdReady() first, which in turn calls poll() to wait for I/O to be available on that FD. This is problematic for wasm32-wasi: although select()/poll() is supported via the poll_oneoff() wasi syscall, that syscall is rather heavyweight and runtime behavior differs in different wasi implementations. The issue is even worse when targeting browsers, given there's no satisfactory way to implement async I/O as a synchronous syscall, so existing JS polyfills for wasi often give up and simply return ENOSYS. Before we have a proper I/O manager that avoids poll_oneoff() for async I/O on wasm, this patch improves the status quo a lot by merely pretending all FDs are "nonblocking". Read/write on FDs will directly invoke read()/write(), which are much more reliably handled in existing wasi implementations, especially those in browsers. Fixes #23275 and the following test cases: T7773 isEOF001 openFile009 T4808 cgrun025 Approved by CLC proposal #234: https://github.com/haskell/core-libraries-committee/issues/234
-
Cheng Shao authored
-
-
