Skip to content
Snippets Groups Projects
Select Git revision
20 results
Search by author
  • Any Author
  • Joris Burgers Joris Burgers jorwas
  • Reinier Maas Reinier Maas trac-simplifierticks
  • Reinier Maas Reinier Maas ReinierMaas
  • Victor Cacciari Miraldo Victor Cacciari Miraldo VictorCMiraldo
4 authors
  1. Jun 12, 2024
  3. Jun 08, 2024
  5. Jun 05, 2024
  7. May 28, 2024
    • Teo Camarasu's avatar
      template-haskell: Move wired-ins to ghc-internal · 228dcae6
      Teo Camarasu authored and Teo Camarasu's avatar Teo Camarasu committed 
      Thus we make `template-haskell` reinstallable and keep it as the public
API for Template Haskell.
All of the wired-in identifiers are moved to `ghc-internal`.
This necessitates also moving much of `ghc-boot-th` into `ghc-internal`.
These modules are then re-exported from `ghc-boot-th` and
`template-haskell`.
To avoid a dependency on `template-haskell` from `lib:ghc`, we instead
depend on the TH ASTs via `ghc-boot-th`.

As `template-haskell` no longer has special status, we can drop the
logic adding an implicit dependency on `template-haskell` when using TH.
We can also drop the `template-haskell-next` package, which was
previously used when bootstrapping.

When bootstrapping, we need to vendor the TH AST modules from
`ghc-internal` into `ghc-boot-th`. This is controlled by the `bootstrap`
cabal flag as before. See Note [Bootstrapping Template Haskell].

We split out a GHC.Internal.TH.Lift module resolving #24752.
This module is only built when not bootstrapping.

Resolves #24703

-------------------------
Metric Increase:
    ghc_boot_th_dir
    ghc_boot_th_so
-------------------------
      228dcae6
  9. May 16, 2024
    • Adam Gundry's avatar
      Representation-polymorphic HasField (fixes #22156) · b84b91f5
      Adam Gundry authored and Marge Bot's avatar Marge Bot committed 
      This generalises the HasField class to support representation polymorphism,
so that instead of

    type HasField :: forall {k} . k -> Type -> Type -> Constraint

we have

    type HasField :: forall {k} {r_rep} {a_rep} . k -> TYPE r_rep -> TYPE a_rep -> Constraint
      b84b91f5
  11. Apr 27, 2024
  13. Apr 20, 2024
    • Sebastian Graf's avatar
      Make `seq#` a magic Id and inline it in CorePrep (#24124) · 385cd1c4
      Sebastian Graf authored and Marge Bot's avatar Marge Bot committed 
      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.
      385cd1c4
  15. Apr 03, 2024
    • Duncan Coutts's avatar
      Accept changes to base-exports · 1adc6fa4
      Duncan Coutts authored and Marge Bot's avatar Marge Bot committed 
      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.
      1adc6fa4
  17. Mar 19, 2024
    • Matthew Craven's avatar
      CorePrep: Rework lowering of BigNat# literals · b56d2761
      Matthew Craven authored and Marge Bot's avatar Marge Bot committed 
      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
      b56d2761
  19. Mar 09, 2024
  21. Mar 08, 2024
  23. Mar 06, 2024
  25. Feb 27, 2024
  27. Feb 25, 2024
  29. Feb 17, 2024
  31. Feb 16, 2024
  33. Feb 15, 2024
  35. Feb 08, 2024
    • Ben Gamari's avatar
      Move `base` to `ghc-internal` · 44f6557a
      Ben Gamari authored and Marge Bot's avatar Marge Bot committed 
      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
      44f6557a
  37. Jan 14, 2024
  39. Jan 07, 2024
  41. Nov 17, 2023
  43. Nov 09, 2023
  45. Nov 01, 2023
  47. Oct 19, 2023
  49. Sep 27, 2023
  51. Sep 01, 2023
  53. Aug 23, 2023
  55. Jul 22, 2023
  57. Jul 08, 2023