Duncan Coutts authored 1 year ago and Marge Bot committed 11 months ago

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.

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

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

Here we add the unit ID to the info table provenance structure.

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.

Such that we can add new helpers into GHC.InfoProv.Types without
breakage.

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

This was simply reexporting things from `ghc-prim`. Instead reexport
these directly from `Data.Kind`. Also add build ordering dependency to
work around #23942.

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

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

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

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

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

* -he profiling mode
* -he profiling selector
* --automatic-era-increment

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

Teo Camarasu authored 2 years ago and Marge Bot committed 1 year ago

- 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

Bumps haddock submodule due to testsuite output changes.

Sylvain Henry authored 1 year ago and Marge Bot committed 1 year ago

First step towards fixing #24331. Replace foreign prim imports with real
primops.

Teo Camarasu authored 1 year ago and Marge Bot committed 1 year ago

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>

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.