[Git][ghc/ghc][wip/marge_bot_batch_merge_job] 14 commits: llvmGen: Adapt to allow use of new pass manager.
Marge Bot (@marge-bot)
gitlab at gitlab.haskell.org
Thu Feb 8 02:46:07 UTC 2024
Marge Bot pushed to branch wip/marge_bot_batch_merge_job at Glasgow Haskell Compiler / GHC
Commits:
4475d160 by Ben Gamari at 2024-02-07T21:45:10-05:00
llvmGen: Adapt to allow use of new pass manager.
We now must use `-passes` in place of `-O<n>` due to #21936.
Closes #21936.
- - - - -
2d4ac9dc by Matthew Pickering at 2024-02-07T21:45:11-05:00
testsuite: Mark length001 as fragile on javascript
Modifying the timeout multiplier is not a robust way to get this test to
reliably fail. Therefore we mark it as fragile until/if javascript ever
supports the stack limit.
- - - - -
c7244cd9 by Matthew Pickering at 2024-02-07T21:45:11-05:00
Javascript: Don't filter out rtsDeps list
This logic appears to be incorrect as it would drop any dependency which
was not in a direct dependency of the package being linked.
In the ghc-internals split this started to cause errors because
`ghc-internal` is not a direct dependency of most packages, and hence
important symbols to keep which are hard coded into the js runtime were
getting dropped.
- - - - -
6c99928f by Ben Gamari at 2024-02-07T21:45:11-05:00
base: Cleanup whitespace in cbits
- - - - -
c770c482 by Ben Gamari at 2024-02-07T21:45:11-05:00
Move `base` to `ghc-internal`
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
- - - - -
f1030243 by Vladislav Zavialov at 2024-02-07T21:45:12-05:00
Haddock comments on infix constructors (#24221)
Rewrite the `HasHaddock` instance for `ConDecl GhcPs` to account for
infix constructors.
This change fixes a Haddock regression (introduced in 19e80b9af252)
that affected leading comments on infix data constructor declarations:
-- | Docs for infix constructor
| Int :* Bool
The comment should be associated with the data constructor (:*), not
with its left-hand side Int.
- - - - -
4420b92a by Ben Gamari at 2024-02-07T21:45:13-05:00
Add os-string as a boot package
Introduces `os-string` submodule. This will be necessary for
`filepath-1.5`.
- - - - -
a5986f73 by Ben Gamari at 2024-02-07T21:45:13-05:00
gitignore: Ignore .hadrian_ghci_multi/
- - - - -
6132c237 by Ben Gamari at 2024-02-07T21:45:13-05:00
hadrian: Set -this-package-name
When constructing the GHC flags for a package Hadrian must take care to
set `-this-package-name` in addition to `-this-unit-id`. This hasn't
broken until now as we have not had any uses of qualified package
imports. However, this will change with `filepath-1.5` and the
corresponding `unix` bump, breaking `hadrian/multi-ghci`.
- - - - -
d6ded006 by Ben Gamari at 2024-02-07T21:45:13-05:00
Bump filepath to 1.5.0.0
Required bumps of the following submodules:
* `directory`
* `filepath`
* `haskeline`
* `process`
* `unix`
* `hsc2hs`
* `Win32`
* `semaphore-compat`
and the addition of `os-string` as a boot package.
- - - - -
836264fb by Matthew Pickering at 2024-02-07T21:45:14-05:00
Use specific clang assembler when compiling with -fllvm
There are situations where LLVM will produce assembly which older gcc
toolchains can't handle. For example on Deb10, it seems that LLVM >= 13
produces assembly which the default gcc doesn't support.
A more robust solution in the long term is to require a specific LLVM
compatible assembler when using -fllvm.
Fixes #16354
- - - - -
e579b9b7 by Matthew Pickering at 2024-02-07T21:45:14-05:00
Update CI images with LLVM 15, ghc-9.6.4 and cabal-install-3.10.2.0
- - - - -
94cc0bb6 by Matthew Pickering at 2024-02-07T21:45:14-05:00
Update bootstrap plans for 9.4.8 and 9.6.4
- - - - -
4726c119 by Matthew Pickering at 2024-02-07T21:45:15-05:00
Add alpine 3_18 release job
This is mainly experimental and future proofing to enable a smooth
transition to newer alpine releases once 3_12 is too old.
- - - - -
30 changed files:
- .gitignore
- .gitlab-ci.yml
- .gitlab/generate-ci/gen_ci.hs
- .gitlab/jobs.yaml
- .gitlab/rel_eng/fetch-gitlab-artifacts/fetch_gitlab.py
- .gitmodules
- compiler/GHC/Builtin/Names.hs
- compiler/GHC/Driver/DynFlags.hs
- compiler/GHC/Driver/Flags.hs
- compiler/GHC/Driver/Pipeline.hs
- compiler/GHC/Driver/Pipeline/Execute.hs
- compiler/GHC/Driver/Pipeline/Phases.hs
- compiler/GHC/Driver/Session.hs
- compiler/GHC/Parser/PostProcess/Haddock.hs
- compiler/GHC/Runtime/Interpreter/JS.hs
- compiler/GHC/Settings.hs
- compiler/GHC/Settings/IO.hs
- compiler/GHC/StgToJS/Linker/Linker.hs
- compiler/GHC/StgToJS/Linker/Utils.hs
- compiler/GHC/StgToJS/Prim.hs
- compiler/GHC/StgToJS/Rts/Rts.hs
- compiler/GHC/StgToJS/Types.hs
- compiler/GHC/SysTools/Tasks.hs
- compiler/GHC/Unit/Types.hs
- compiler/GHC/Utils/Misc.hs
- compiler/ghc.cabal.in
- configure.ac
- distrib/configure.ac.in
- docs/users_guide/9.10.1-notes.rst
- docs/users_guide/phases.rst
The diff was not included because it is too large.
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/f8c4a2925f6101c0d85d3576e07055cdea165fac...4726c11936923d6508eef336f357310def4df1f1
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/f8c4a2925f6101c0d85d3576e07055cdea165fac...4726c11936923d6508eef336f357310def4df1f1
You're receiving this email because of your account on gitlab.haskell.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-commits/attachments/20240207/7a4b8ed6/attachment-0001.html>
More information about the ghc-commits
mailing list