- Feb 13, 2024
-
-
This commit adds JavaScriptFFI as a supported extension when the target platform is wasm32.
-
This commit adds JSFFI desugar logic for the wasm backend.
-
This commit fixes the priorities of ctors generated by GHC codegen on wasm32, see the referred note for details.
-
This commit allows the boxed JSVal type to be used as a foreign argument/result type.
-
This commit allows the javascript calling convention to be used when the target platform is wasm32.
-
The pure Haskell implementation causes i386 regression in unrelated work that can be fixed by using C-based atomic increment, see added comment for details.
-
This commit adds needed constants to deriveConstants. They are used by RTS code in the wasm backend to support the JSFFI logic.
-
- Feb 12, 2024
-
-
Resolves #24421
-
Add support for heap profiling while using the nonmoving collector. We greatly simply the implementation by disabling concurrent collection for GCs when heap profiling is enabled. This entails that the marked objects on the nonmoving heap are exactly the live objects. Note that we match the behaviour for live bytes accounting by taking the size of objects on the nonmoving heap to be that of the segment's block rather than the object itself. Resolves #22221
-
Just remove an out of date block of commented-out code, and tidy up the relevant Notes. See #8317.
-
emcc would sometime output messages like: cache:INFO: generating system asset: symbol_lists/424b44514e43d789148e69e4e7d1c7fdc0350b79.json... (this will be cached in "/emsdk/upstream/emscripten/cache/symbol_lists/424b44514e43d789148e69e4e7d1c7fdc0350b79.json" for subsequent builds) cache:INFO: - ok Cf https://github.com/emscripten-core/emscripten/issues/18607 This breaks our tests matching the stderr output. We avoid this by setting EMCC_LOGGING=0
-
Support linking C sources with JS output of the JavaScript backend. See the added documentation in the users guide. The implementation simply extends the JS linker to use the objects (.o) that were already produced by the emcc compiler and which were filtered out previously. I've also added some options to control the link with C functions (see the documentation about pragmas). With this change I've successfully compiled the direct-sqlite package which embeds the sqlite.c database code. Some wrappers are still required (see the documentation about wrappers) but everything generic enough to be reused for other libraries have been integrated into rts/js/mem.js.
-
This isn't implemented for JS backend objects.
-
Some Haskell codes unsafely cast StablePtr into ptr to compare against NULL. E.g. in direct-sqlite: if castStablePtrToPtr aggStPtr /= nullPtr then where `aggStPtr` is read (`peek`) from zeroed memory initially. We fix this by giving these StablePtr the same representation as other null pointers. It's safe because StablePtr at offset 0 is unused (for this exact reason).
-
- Feb 10, 2024
-
-
The only changes here are that clang15 is now installed on the alpine-3_18 image.
-
Fixes: - #24409 Follow on from: - #21078 and MR !9133 - When we added the JS backend this was forgotten. This patch adds the rightful codeowners.
-
-
The eras profiling mode is useful for tracking the life-time of closures. When a closure is written, the current era is recorded in the profiling header. This records the era in which the closure was created. * Enable with -he * User mode: Use functions ghc-experimental module GHC.Profiling.Eras to modify the era * Automatically: --automatic-era-increment, increases the user era on major collections * The first era is era 1 * -he<era> can be used with other profiling modes to select a specific era If you just want to record the era but not to perform heap profiling you can use `-he --no-automatic-heap-samples`. https://well-typed.com/blog/2024/01/ghc-eras-profiling/ Fixes #24332
-
-
JavaScript codegen: Use GHC's tag inference where JS backend-specific evaluation inference was previously used (#24309)
-
- Feb 08, 2024
-
-
-
Fixes: #24411 Added test T24411 for regression
-
Per #23966, I want the top-level configure to only generate configuration data for Hadrian, not do any "real" tasks on its own. This is part of that effort --- one less file generated by it. (It is still done with a `.in` file, so in a future world non-Hadrian also can easily create this file.) Split modules: - GHC.CmmToLlvm.Config - GHC.CmmToLlvm.Version - GHC.CmmToLlvm.Version.Bounds - GHC.CmmToLlvm.Version.Type This also means we can get rid of the silly `unused.h` introduced in !6803 / 7dfcab2f as temporary kludge. Part of #23966
-
This is mainly experimental and future proofing to enable a smooth transition to newer alpine releases once 3_12 is too old.
-
-
-
There are situations where LLVM will produce assembly which older gcc toolchains can't handle. For example on Deb10, it seems that LLVM >= 13 produces assembly which the default gcc doesn't support. A more robust solution in the long term is to require a specific LLVM compatible assembler when using -fllvm. Fixes #16354
-
Required bumps of the following submodules: * `directory` * `filepath` * `haskeline` * `process` * `unix` * `hsc2hs` * `Win32` * `semaphore-compat` and the addition of `os-string` as a boot package.
-
When constructing the GHC flags for a package Hadrian must take care to set `-this-package-name` in addition to `-this-unit-id`. This hasn't broken until now as we have not had any uses of qualified package imports. However, this will change with `filepath-1.5` and the corresponding `unix` bump, breaking `hadrian/multi-ghci`.
-
-
Introduces `os-string` submodule. This will be necessary for `filepath-1.5`.
-
Rewrite the `HasHaddock` instance for `ConDecl GhcPs` to account for infix constructors. This change fixes a Haddock regression (introduced in 19e80b9a) that affected leading comments on infix data constructor declarations: -- | Docs for infix constructor | Int :* Bool The comment should be associated with the data constructor (:*), not with its left-hand side Int.
-
Here we move a good deal of the implementation of `base` into a new package, `ghc-internal` such that it can be evolved independently from the user-visible interfaces of `base`. While we want to isolate implementation from interfaces, naturally, we would like to avoid turning `base` into a mere set of module re-exports. However, this is a non-trivial undertaking for a variety of reasons: * `base` contains numerous known-key and wired-in things, requiring corresponding changes in the compiler * `base` contains a significant amount of C code and corresponding autoconf logic, which is very fragile and difficult to break apart * `base` has numerous import cycles, which are currently dealt with via carefully balanced `hs-boot` files * We must not break existing users To accomplish this migration, I tried the following approaches: * [Split-GHC.Base]: Break apart the GHC.Base knot to allow incremental migration of modules into ghc-internal: this knot is simply too intertwined to be easily pulled apart, especially given the rather tricky import cycles that it contains) * [Move-Core]: Moving the "core" connected component of base (roughly 150 modules) into ghc-internal. While the Haskell side of this seems tractable, the C dependencies are very subtle to break apart. * [Move-Incrementally]: 1. Move all of base into ghc-internal 2. Examine the module structure and begin moving obvious modules (e.g. leaves of the import graph) back into base 3. Examine the modules remaining in ghc-internal, refactor as necessary to facilitate further moves 4. Go to (2) iterate until the cost/benefit of further moves is insufficient to justify continuing 5. Rename the modules moved into ghc-internal to ensure that they don't overlap with those in base 6. For each module moved into ghc-internal, add a shim module to base with the declarations which should be exposed and any requisite Haddocks (thus guaranteeing that base will be insulated from changes in the export lists of modules in ghc-internal Here I am using the [Move-Incrementally] approach, which is empirically the least painful of the unpleasant options above Bumps haddock submodule. Metric Decrease: haddock.Cabal haddock.base Metric Increase: MultiComponentModulesRecomp T16875 size_hello_artifact -
-
This logic appears to be incorrect as it would drop any dependency which was not in a direct dependency of the package being linked. In the ghc-internals split this started to cause errors because `ghc-internal` is not a direct dependency of most packages, and hence important symbols to keep which are hard coded into the js runtime were getting dropped.
-
Modifying the timeout multiplier is not a robust way to get this test to reliably fail. Therefore we mark it as fragile until/if javascript ever supports the stack limit.
-
-
- Feb 07, 2024
-
-
Instead we were setting CONF_GCC_LINK_OPTS_STAGE2 which meant that we were missing passing `--target` when invoking the linker. Fixes #24414
-
In cdddeb0f, we set up a workaround for #24324 in the in-tree configure script, but forgot to update the bindist configure script accordingly. This updates it.
-
-
