- Apr 27, 2024
-
-
Closes #24288, implements CLC proposal https://github.com/haskell/core-libraries-committee/issues/238. Adds a MonadFix instance for tuples, permitting value recursion in the "native" writer monad and bringing consistency with the existing instance for transformers's WriterT (and, to a lesser extent, for Solo).
-
- 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.
-
- Apr 04, 2024
-
-
Before this patch: data ArgPat p = InvisPat (LHsType p) | VisPat (LPat p) With this patch: data Pat p = ... | InvisPat (LHsType p) ... And the same transformation in the TH land. The rest of the changes is just updating code to handle new AST and writing tests to check if it is possible to create invalid states using TH. Metric Increase: MultiLayerModulesTH_OneShot -
-
- Apr 03, 2024
-
-
All the changes are in fact not changes at all. Previously, the IoSubSystem data type was defined in GHC.RTS.Flags and exported from both GHC.RTS.Flags and GHC.IO.SubSystem. Now, the data type is defined in GHC.IO.SubSystem and still exported from both modules. Therefore, the same exports and same instances are still available from both modules. But the base-exports records only the defining module, and so it looks like a change when it is fully compatible. Related: we do add a deprecation to the export of the type via GHC.RTS.Flags, telling people to use the export from GHC.IO.SubSystem. Also the sort order for some unrelated Show instances changed. No idea why. The same changes apply in the other versions, with a few more changes due to sort order weirdness.
-
- Mar 19, 2024
-
-
Don't use bigNatFromWord#, because that's terrible: * We shouldn't have to traverse a linked list at run-time to build a BigNat# literal. That's just silly! * The static List object we have to create is much larger than the actual BigNat#'s contents, bloating code size. * We have to read the corresponding interface file, which causes un-tracked implicit dependencies. (#23942) Instead, encode them into the appropriate platform-dependent sequence of bytes, and generate code that copies these bytes at run-time from an Addr# literal into a new ByteArray#. A ByteArray# literal would be the correct thing to generate, but these are not yet supported; see also #17747. Somewhat surprisingly, this change results in a slight reduction in compiler allocations, averaging around 0.5% on ghc's compiler performance tests, including when compiling programs that contain no bignum literals to begin with. The specific cause of this has not been investigated. Since this lowering no longer reads the interface file for GHC.Num.BigNat, the reasoning in Note [Depend on GHC.Num.Integer] is obsoleted. But the story of un-tracked built-in dependencies remains complex, and Note [Tracking dependencies on primitives] now exists to explain this complexity. Additionally, many empty imports have been modified to refer to this new note and comply with its guidance. Several empty imports necessary for other reasons have also been given brief explanations. Metric Decrease: MultiLayerModulesTH_OneShot
-
- Mar 10, 2024
-
-
Ben Gamari authored
It appears that this was
-
Ben Gamari authored
This provides PVP compliance while maintaining a clear correspondence between GHC releases and `ghc-internal` versions.
-
- Mar 09, 2024
-
-
Ben Gamari authored
-
Ben Gamari authored
Here we add the unit ID to the info table provenance structure.
-
Ben Gamari authored
Previously we would eagerly allocate `InfoTableEnt`s for each info table registered in the info table provenance map. However, this costs considerable memory and initialization time. Instead we now lazily decode these tables. This allows us to use one-third the memory *and* opens the door to taking advantage of sharing opportunities within a module. This required considerable reworking since lookupIPE now must be passed its result buffer.
-
Ben Gamari authored
Such that we can add new helpers into GHC.InfoProv.Types without breakage.
-
- Mar 08, 2024
-
-
This was simply reexporting things from `ghc-prim`. Instead reexport these directly from `Data.Kind`. Also add build ordering dependency to work around #23942.
-
Here we introduce the `Backtraces` type and associated machinery for attaching these via `ExceptionContext`. These has a few compile-time regressions (`T15703` and `T9872d`) due to the additional dependencies in the exception machinery. As well, there is a surprisingly large regression in the `size_hello_artifact` test. This appears to be due to various `Integer` and `Read` bits now being reachable at link-time. I believe it should be possible to avoid this but I have accepted the change for now to get the feature merged. CLC Proposal: https://github.com/haskell/core-libraries-committee/issues/199 GHC Proposal: https://github.com/ghc-proposals/ghc-proposals/pull/330 Metric Increase: T15703 T9872d size_hello_artifact
-
-
Here we introduce the `ExceptionContext` type and `ExceptionAnnotation` class, allowing dynamically-typed user-defined annotations to be attached to exceptions. CLC Proposal: https://github.com/haskell/core-libraries-committee/issues/199 GHC Proposal: https://github.com/ghc-proposals/ghc-proposals/pull/330
-
- Mar 06, 2024
-
-
* -he profiling mode * -he profiling selector * --automatic-era-increment CLC proposal #254 - https://github.com/haskell/core-libraries-committee/issues/254
-
- Mar 01, 2024
-
-
This implements Proposal 0475, introducing the `ListTuplePuns` extension which is enabled by default. Disabling this extension makes it invalid to refer to list, tuple and sum type constructors by using built-in syntax like `[Int]`, `(Int, Int)`, `(# Int#, Int# #)` or `(# Int | Int #)`. Instead, this syntax exclusively denotes data constructors for use with `DataKinds`. The conventional way of referring to these data constructors by prefixing them with a single quote (`'(Int, Int)`) is now a parser error. Tuple declarations have been moved to `GHC.Tuple.Prim` and the `Solo` data constructor has been renamed to `MkSolo` (in a previous commit). Unboxed tuples and sums now have real source declarations in `GHC.Types`. Unit and solo types for tuples are now called `Unit`, `Unit#`, `Solo` and `Solo#`. Constraint tuples now have the unambiguous type constructors `CTuple<n>` as well as `CUnit` and `CSolo`, defined in `GHC.Classes` like before. A new parser construct has been added for the unboxed sum data constructor declarations. The type families `Tuple`, `Sum#` etc. that were intended to provide nicer syntax have been omitted from this change set due to inference problems, to be implemented at a later time. See the MR discussion for more info. Updates the submodule utils/haddock. Updates the cabal submodule due to new language extension. Metric Increase: haddock.base Metric Decrease: MultiLayerModulesTH_OneShot size_hello_artifact Proposal document: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0475-tuple-syntax.rst Merge request: ghc/ghc!8820 Tracking ticket: ghc/ghc#21294
-
- Feb 27, 2024
-
-
- Use ClosureType for InfoProv.ipDesc. - Use ClosureType for CloneStack.closureType. - Now ghc-heap re-exports this type from ghc-internal. See the accompanying CLC proposal: https://github.com/haskell/core-libraries-committee/issues/210 Resolves #22600
-
- Feb 25, 2024
-
-
Ben Gamari authored
Bumps haddock submodule due to testsuite output changes.
-
- Feb 17, 2024
-
-
-
First step towards fixing #24331. Replace foreign prim imports with real primops.
-
- Feb 16, 2024
-
-
The corresponding C function was introduced in ba73a807. As part of #22264. Resolves #24228 The CLC proposal was disccused at: https://github.com/haskell/core-libraries-committee/issues/230 Co-authored-by:
Ben Gamari <bgamari.foss@gmail.com>
-
- Feb 15, 2024
-
-
This patch builds on 5077416e and modifies the base API to reflect the new RTS flag. CLC proposal #243 - https://github.com/haskell/core-libraries-committee/issues/243 Fixes #24337
-
Adds `sortOn` to `Data.List.NonEmpty`, and adds comments describing when to use it, compared to `sortWith` or `sortBy . comparing`. The aim is to smooth out the API between `Data.List`, and `Data.List.NonEmpty`. This change has been discussed in the [clc issue](https://github.com/haskell/core-libraries-committee/issues/227).
-
- Feb 10, 2024
-
-
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
-
- Feb 08, 2024
-
-
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
-
- Jan 14, 2024
-
-
CLC proposal #226 https://github.com/haskell/core-libraries-committee/issues/226
-
- Jan 07, 2024
-
-
Implements CLC proposal #154: https://github.com/haskell/core-libraries-committee/issues/154 * add unaligned addr primops * add tests * accept tests * add documentation * fix js primops * uncomment in access ops * use Word64 in tests * apply suggestions * remove extra file * move docs * remove random options * use setByteArray# primop * better naming * update base-exports test * add base-exports for other architectures
-
- Nov 17, 2023
- Nov 09, 2023
-
-
Closes #20532. This implements CLC proposal 104: https://github.com/haskell/core-libraries-committee/issues/104 The design is explained in Note [DataToTag overview] in GHC.Tc.Instance.Class. This replaces the existing `dataToTag#` primop. These metric changes are not "real"; they represent Unique-related flukes triggering on a different set of jobs than they did previously. See also #19414. Metric Decrease: T13386 T8095 Metric Increase: T13386 T8095 Co-authored-by:
Simon Peyton Jones <simon.peytonjones@gmail.com>
-
- Nov 01, 2023
-
-
"where" should be after the injectivity annotation.
-
- Oct 19, 2023
- Sep 27, 2023
-
-
- Sep 01, 2023
-
-
See https://github.com/haskell/core-libraries-committee/issues/167 for discussion Metric Decrease: T8095 T13386 Metric Increase: T13386 T8095 T8095 ghc/alloc decreased on x86_64, but increased on aarch64. T13386 ghc/alloc decreased on x86_64-windows, but increased on other platforms. Neither has anything to do with `foldl'`, so I conclude that both are flaky.
-
- Aug 23, 2023
-
-
- Aug 17, 2023
-
-
