Matthew Pickering authored 1 year ago and Marge Bot committed 1 year ago

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

Owen Shepherd authored 1 year ago and Marge Bot committed 1 year ago

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).

Ben Gamari authored 1 year ago and Marge Bot committed 1 year ago

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

jship authored 1 year ago and Marge Bot committed 1 year ago

CLC proposal #226 https://github.com/haskell/core-libraries-committee/issues/226

oberblastmeister authored 1 year ago and Marge Bot committed 1 year ago

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

Bodigrim authored 1 year ago and Marge Bot committed 1 year ago

Approved by CLC in https://github.com/haskell/core-libraries-committee/issues/68#issuecomment-1221409837

Matthew Craven authored 2 years ago and Marge Bot committed 1 year ago

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>

Krzysztof Gogolewski authored 1 year ago and Marge Bot committed 1 year ago

"where" should be after the injectivity annotation.

Hécate Moonlight authored 1 year ago and Marge Bot committed 1 year ago

Proposal link: https://github.com/haskell/core-libraries-committee/issues/182

Bodigrim authored 1 year ago and Marge Bot committed 1 year ago

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.

Ben Gamari authored 1 year ago and Marge Bot committed 1 year ago

This addresses an odd asymmetry in the ByteArray# primops, which
previously provided unsafeFreezeByteArray# but no corresponding
thaw operation.

Closes #22710

Ben Gamari authored 2 years ago and Marge Bot committed 1 year ago

This adds testing infrastructure to ensure that changes in core
libraries (e.g. `base` and `ghc-prim`) are caught in CI.