- Apr 20, 2024
-
-
We can save much code and explanation in Tag Inference and StgToCmm by making `seq#` a known-key Magic Id in `GHC.Internal.IO` and inline this definition in CorePrep. See the updated `Note [seq# magic]`. I also implemented a new `Note [Flatten case-bind]` to get better code for otherwise nested case scrutinees. I renamed the contructors of `ArgInfo` to use an `AI` prefix in order to resolve the clash between `type CpeApp = CoreExpr` and the data constructor of `ArgInfo`, as well as fixed typos in `Note [CorePrep invariants]`. Fixes #24252 and #24124.
-
Fixes #23764 Implements https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0640-tyop-quantification-order.rst Updates haddock submodule.
-
- Apr 19, 2024
-
-
-
Include the location of the prefix @ in the span for InVisPat. Also removes unnecessary annotations from HsTP. Contributes to #24669
-
And remove unused parameter in checkPatBind Contributes to #24669
-
-
Also extend the test to confirm. Addresses #24669, 1 of 4
-
This MR adjusts SetLevels so that it is less eager to float a HNF (lambda or constructor application) out of a lambda, unless it gets to top level. Data suggests that this change is a small net win: * nofib bytes-allocated falls by -0.09% (but a couple go up) * perf/should_compile bytes-allocated falls by -0.5% * perf/should_run bytes-allocated falls by -0.1% See !12410 for more detail. When fiddling elsewhere, I also found that this patch had a huge positive effect on the (very delicate) test perf/should_run/T21839r But that improvement doesn't show up in this MR by itself. Metric Decrease: MultiLayerModulesRecomp T15703 parsing001 -
isCross() was a misnamed because it assumed that all cross targets would provide a target wrapper, but the two most common cross targets (javascript, wasm) don't need a target wrapper. Therefore we rename this predicate to `needsTargetWrapper()` so situations in the testsuite where we can check whether running executables requires a target wrapper or not.
-
- Apr 17, 2024
-
-
Rather than `hide`. Closes #24659.
-
This was missing part of the unit ID meaning it would 404. Resolves #24674
-
We need a temporary directory, not a file.
-
-
This is used in exact printing to store comments coming after the `where` keyword but before any comments allocated to imports or decls. It is used in ghc-exactprint, see https://github.com/alanz/ghc-exactprint/commit/44bbed311fd8f0d053053fef195bf47c17d34fa7
-
While the RTS does attempt to mask signals, it may be that a foreign library unmasks them. This previously caused benign warnings which we now ignore. See #24610.
-
- Include all the .html files and assets in the job artefacts - Include all the .pdf files in the job artefacts - Mark the artefact as an "exposed" artefact meaning it turns up in the UI. Resolves #24651
-
Add a new method to the Instruction class to check if we can eliminate a jump in favour of fallthrough control flow. Fixes #24507
-
This MR addresses #24463. It's all explained in the new Note [Cloning CoVars and TyVars]
-
-
Promoting template-haskell from a stage0 to a stage1 package means that we can much more easily refactor template-haskell. We implement this by duplicating the in-tree `template-haskell`. A new `template-haskell-next` library is autogenerated to mirror `template-haskell` `stage1:ghc` to depend on the new interface of the library including the `Binary` instances without adding an explicit dependency on `template-haskell`. This is controlled by the `bootstrap-th` cabal flag When building `template-haskell` modules as part of this vendoring we do not have access to quote syntax, so we cannot use variable quote notation (`'Just`). So we either replace these with hand-written `Name`s or hide the code behind CPP. We can remove the `th_hack` from hadrian, which was required when building stage0 packages using the in-tree `template-haskell` library. For more details see Note [Bootstrapping Template Haskell]. Resolves #23536 Co-Authored-By:
Sebastian Graf <sgraf1337@gmail.com> Co-Authored-By:
Matthew Craven <5086-clyring@users.noreply.gitlab.haskell.org>
-
- Apr 15, 2024
-
-
Alex Mason authored
Also adds a test for MO_S_Mul2
-
- Apr 12, 2024
-
-
Previously, the logic for checking if a data constructor needs a wrapper or not would take into account whether the constructor's fields have explicit strictness (e.g., `data T = MkT !Int`), but the logic would _not_ take into account whether `StrictData` was enabled. This meant that something like `type data T = MkT Int` would incorrectly generate a wrapper for `MkT` if `StrictData` was enabled, leading to the horrible errors seen in #24620. To fix this, we disable generating wrappers for `type data` constructors altogether. Fixes #24620. Co-authored-by:Ryan Scott <ryan.gl.scott@gmail.com>
-
It is sometimes more useful to know how much bigger or smaller the nursery got when it is resized. In particular I am trying to investigate situations where we end up with fragmentation due to the nursery (#24577)
-
-
-
Closes #24640.
-
Closes #24646.
-
Fixes #23680.
-
Closes #24609.
-
As proposed in #21461. Closes #21540.
-
See #24634.
-
Fixes #24487
-
The implementation of `checkHomeUnitsClosed` was traversing every single path in the unit dependency graph - this grows exponentially and quickly grows to be infeasible on larger unit dependency graphs. Instead we replace this with a faster implementation which follows from the specificiation of the closure property - there is a closure error if there are units which are both are both (transitively) depended upon by home units and (transitively) depend on home units, but are not themselves home units. To compute the set of units required for closure, we first compute the closure of the unit dependency graph, then the transpose of this closure, and find all units that are reachable from the home units in the transpose of the closure.
-
Over the years the users guide's language extension documentation has gone through quite a few refactorings. In the process some of the descriptions have been rendered non-sensical. For instance, the description of `NoImplicitPrelude` actually describes the semantics of `ImplicitPrelude`. To fix this we: * ensure that all extensions are named in their "positive" sense (e.g. `ImplicitPrelude` rather than `NoImplicitPrelude`). * rework the documentation to avoid flag-oriented wording like "enable" and "disable" * ensure that the polarity of the documentation is consistent with reality. Fixes #23895.
-
- Apr 10, 2024
-
-
The XRec for [LIdP pass] is not needed for exact printing, remove it.
-
-
This commit makes the symbol cache that was used by the external interpreter available for the internal interpreter too. This follows from the analysis in #23415 that suggests the internal interpreter could benefit from this cache too, and that there is no good reason not to have the cache for it too. It also makes it a bit more uniform to have the symbol cache range over both the internal and external interpreter. This commit also refactors the cache into a function which is used by both `lookupSymbol` and also by `lookupSymbolInDLL`, extending the caching logic to `lookupSymbolInDLL` too.
-
Rewrite the implementation of `addDLL` as a wrapper around the more principled `loadNativeObj` rts linker function. The latter should be preferred while the former is preserved for backwards compatibility. `loadNativeObj` was previously only available on ELF platforms, so this commit further refactors the rts linker to transform loadNativeObj_ELF into loadNativeObj_POSIX, which is available in ELF and MachO platforms. The refactor made it possible to remove the `dl_mutex` mutex in favour of always using `linker_mutex` (rather than a combination of both). Lastly, we implement `loadNativeObj` for Windows too.
-
See the primary Note [Looking up symbols in the relevant objects] for a more in-depth explanation. When dynamically loading a Haskell symbol (typical when running a splice or GHCi expression), before this commit we would search for the symbol in all dynamic libraries that were loaded. However, this could be very inefficient when too many packages are loaded (which can happen if there are many package dependencies) because the time to lookup the would be linear in the number of packages loaded. This commit drastically improves symbol loading performance by introducing a mapping from units to the handles of corresponding loaded dlls. These handles are returned by dlopen when we load a dll, and can then be used to look up in a specific dynamic library. Looking up a given Name is now much more precise because we can get lookup its unit in the mapping and lookup the symbol solely in the handles of the dynamic libraries loaded for that unit. In one measurement, the wait time before the expression was executed went from +-38 seconds down to +-2s. This commit also includes Note [Symbols may not be found in pkgs_loaded], explaining the fallback to the old behaviour in case no dll can be found in the unit mapping for a given Name. Fixes #23415 Co-authored-by:
Rodrigo Mesquita <(@alt-romes)>
-
Fixes a memory leak in rts/linker/PEi386.c
-
