[Git][ghc/ghc][wip/marge_bot_batch_merge_job] 17 commits: base: add SrcLoc changes to changelog, 4.21.0.0

Wed Jan 29 03:18:43 UTC 2025

Marge Bot pushed to branch wip/marge_bot_batch_merge_job at Glasgow Haskell Compiler / GHC

Commits:
8071bad8 by Jeffrey Young at 2025-01-28T21:45:32-05:00
base: add SrcLoc changes to changelog, 4.21.0.0

I accidentally dropped this in !13381

- closes #25614

See:

- ea4587794b9e3a098f9c02bd6cea2294af2539ce  (the 13381 commit)
- Issue #25614

- - - - -
583fc267 by M Farkas-Dyck at 2025-01-28T22:17:13-05:00
Rename `cloneBndrs` and such — now all the monadic ones have an `M` suffix.

We now have `cloneBndrs` and `cloneRecIdBndrs` which take a `UniqSupply` argument, and `cloneBndrsM` and `cloneRecIdBndrsM` which rather have a `MonadUnique` constraint.

- - - - -
25681b60 by Matthew Farkas-Dyck at 2025-01-28T22:17:13-05:00
Use `Infinite` in unique generation, and clean up some other partial uni patterns as well.

Also drop the losing `instance MonadFail UniqSM`.

We redefine `getUniquesM` in terms of `Infinite` rather than `[]`, and define another method `getUniqueListM` for the use sites where we actually want a `[]`.
Thus, at many sites, we can avoid the partiality of the empty list case.

We also define `withUniques`, `withUniquesM`, and `withUniquesM'`, which traverse an arbitrary `Traversable` structure and introduce a `Unique` for each element.
This allows us to redefine various functions to operate on more appropriate types than `[]` and avoid further partiality (in the form of incomplete-uni-patterns).

- - - - -
1b017761 by M Farkas-Dyck at 2025-01-28T22:17:13-05:00
Use `Infinite` in `GHC.Tc.Deriv.Functor`.

Make the list of variables to use in generated code `Infinite`, to avoid panicking on the (now impossible) empty list case.

- - - - -
773ce0f5 by M Farkas-Dyck at 2025-01-28T22:17:13-05:00
Use `Infinite` in `GHC.Runtime.Debugger`.

Make the list of available names `Infinite`, to avoid panicking on the (now impossible) empty list case.

- - - - -
6fe0e844 by M Farkas-Dyck at 2025-01-28T22:17:13-05:00
Avoid incomplete-uni-patterns in `GHC.Cmm.DebugBlock`.

We do so by changing the type of `BlockContext` to statically (in GHC) exclude the possibility of Cmm statics, and using `NonEmpty` lists of `BlockContext`s in `cmmDebugGen`.

- - - - -
363e13f5 by M Farkas-Dyck at 2025-01-28T22:17:13-05:00
Avoid incomplete-uni-patterns in `GHC.Types.Literal`.

We do so by introducing `mkLitNumberWrap'` whose ultimate codomain is `Integer` rather than `Literal`, and then use that rather than `mkLitNumberWrap` where we just need the number rather than the `Literal`.

- - - - -
3303bedf by M Farkas-Dyck at 2025-01-28T22:17:13-05:00
Avoid incomplete-uni-patterns in `GHC.CmmToAsm.X86.CodeGen`.

- Match the vector element list only once in `shuffleInstructions`.
- Define `isSuitableFloatingPointLit_maybe` which returns `Just` the width if the lit is indeed suitable.

- - - - -
91fc805c by M Farkas-Dyck at 2025-01-28T22:17:13-05:00
Clean up more incomplete uni patterns.

At some sites, we merely panic if the `[]` or `Maybe` is empty when we convert to `NonEmpty` or `Identity`, but at least now we make it explicit.

At other sites, we are able to use more precise types and avoid the partiality altogether. To do so, we redefine various functions to operate over `Traversable` arguments, so we can use the appropriate shape where known.

- - - - -
4c444441 by M Farkas-Dyck at 2025-01-28T22:17:13-05:00
Outline `expectJustPanic`.

- - - - -
593bd56f by Marc Scholten at 2025-01-28T22:17:20-05:00
base: Introduce Data.Enum.enumerate (CLC #306)

https://github.com/haskell/core-libraries-committee/issues/306

- - - - -
59337372 by Ben Gamari at 2025-01-28T22:17:21-05:00
base: Update description of locking behavior
- - - - -
34fb39b3 by Ben Gamari at 2025-01-28T22:17:23-05:00
base: Fix @since annotation of Data.Bounded

Fixes #25615.

- - - - -
805ed7c4 by Ben Gamari at 2025-01-28T22:17:25-05:00
StgToByteCode: Fix overly-broad handling of Addr# literals

Previously we assumed that all unlifted types were `Addr#` but this
isn't true. As noted in #25638, unlifted nullary data constructor
workers can also appear at the top-level and are obviously not of type
`Addr#`.

Note that there is more work to be done to properly handle unlifted data
constructors (especially nullary; see #25636). However, this is a small
step in the right direction.

Closes #25641.

- - - - -
4bee43b8 by Ben Gamari at 2025-01-28T22:17:25-05:00
StgToByteCode: Assert that PUSH_G'd values are lifted

We currently do not support top-level unlifted data constructor applications,
therefore this is a safe assertion.

Pointed out by @sheaf.
- - - - -
e5259b46 by Ben Gamari at 2025-01-28T22:17:26-05:00
gitlab-ci: Run test-primops testsuite in ~"full-ci" pipeline

Closes #25654.

- - - - -
91833c0b by Matthew Pickering at 2025-01-28T22:17:27-05:00
bytecode: Do not generate `SLIDE x 0` instructions

SLIDE x 0 is a no-op as it means to shift x elements of the stack by no
spaces. In the interpreter, this results in a loop which copies an array
element into the same place.

I have instrumented GHCi to count how many of these instructions are interpreted.
The workload was `ghc` compiling two simple modules.

Total no-op slides: 7793476
Total slides: 11413289
Percentage useless (slides): 68%
Percentage uselss of total instructions: 9%

- - - - -

30 changed files:

- .gitlab-ci.yml
- compiler/GHC/Cmm/DebugBlock.hs
- compiler/GHC/Cmm/MachOp.hs
- compiler/GHC/Cmm/ThreadSanitizer.hs
- compiler/GHC/Cmm/Utils.hs
- compiler/GHC/CmmToAsm/AArch64/CodeGen.hs
- compiler/GHC/CmmToAsm/CFG.hs
- compiler/GHC/CmmToAsm/PPC/Instr.hs
- compiler/GHC/CmmToAsm/Reg/Graph/Stats.hs
- compiler/GHC/CmmToAsm/Reg/Linear.hs
- compiler/GHC/CmmToAsm/Reg/Linear/JoinToTargets.hs
- compiler/GHC/CmmToAsm/Reg/Liveness.hs
- compiler/GHC/CmmToAsm/X86/CodeGen.hs
- compiler/GHC/CmmToLlvm/CodeGen.hs
- compiler/GHC/Core/Make.hs
- compiler/GHC/Core/Opt/ConstantFold.hs
- compiler/GHC/Core/Opt/SetLevels.hs
- compiler/GHC/Core/Opt/Simplify/Iteration.hs
- compiler/GHC/Core/Opt/Simplify/Utils.hs
- compiler/GHC/Core/Opt/SpecConstr.hs
- compiler/GHC/Core/Opt/Specialise.hs
- compiler/GHC/Core/Opt/WorkWrap/Utils.hs
- compiler/GHC/Core/Subst.hs
- compiler/GHC/Core/TyCo/Tidy.hs
- compiler/GHC/Core/Unify.hs
- compiler/GHC/CoreToStg/Prep.hs
- compiler/GHC/Data/List/Infinite.hs
- compiler/GHC/Data/Maybe.hs
- compiler/GHC/Driver/Pipeline/Execute.hs
- compiler/GHC/Driver/Session.hs

The diff was not included because it is too large.

View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/9955f7371eb210c53f53d0e42216fefb09b4fdad...91833c0be12a22767511a4fa6b774dedbdcef9d4

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/9955f7371eb210c53f53d0e42216fefb09b4fdad...91833c0be12a22767511a4fa6b774dedbdcef9d4
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/20250128/94f5520c/attachment-0001.html>