GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2024-03-21T09:39:17Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/24548configure ignores LDFLAGS2024-03-21T09:39:17ZRodrigo Mesquitaconfigure ignores LDFLAGS## Summary
It seems that `./configure` ignores `LDFLAGS` (whereas `ghc-toolchain` doesn't).
## Steps to reproduce
`LDFLAGS="-Lsomethingbogus" ./configure`
You should get
```
There are some differences between the toolchain configure...## Summary
It seems that `./configure` ignores `LDFLAGS` (whereas `ghc-toolchain` doesn't).
## Steps to reproduce
`LDFLAGS="-Lsomethingbogus" ./configure`
You should get
```
There are some differences between the toolchain configured by "configure" (hadrian/cfg/default.target) and the toolchain configured by the "ghc-toolchain" program (hadrian/cfg/default.target.ghc-toolchain).
20c20
< { ccLinkProgram = Program { prgPath = "/usr/bin/gcc" , prgFlags = ["--target=arm64-apple-darwin","-Wl,-no_fixup_chains","-Wl,-no_warn_duplicate_libraries"] }
---
> { ccLinkProgram = Program { prgPath = "/usr/bin/gcc" , prgFlags = ["--target=arm64-apple-darwin","-Lsomethingbogus","-Wl,-no_fixup_chains","-Wl,-no_warn_duplicate_libraries"] }
```
## Expected behavior
`./configure`-based toolchain configuration should also consider `LDFLAGS` into the cclinker program.
I suppose this is not a priority because `ghc-toolchain` is already doing this right and we ultimately want to move toolchain configuration to it. It is yet another datapoint to hurry on the move (BTW, I think it has been two releases since ghc-toolchain is available opt-in... perhaps the time to make the move is drawing close?).
## Environment
* GHC version used: HEAD
Optional:
* Operating System: macOS
* System Architecture: aarch64https://gitlab.haskell.org/ghc/ghc/-/issues/24544Suggestion to add entity information to HieFile2024-03-19T15:09:52ZPatrickSuggestion to add entity information to HieFileNamespace is used to distinguish between different kinds of names that appear in a Haskell program in ghc.
But namespaces are falling too much behind the the number of entities that ghc can offers.
* By ghc 9.8.2: we are only having:`V...Namespace is used to distinguish between different kinds of names that appear in a Haskell program in ghc.
But namespaces are falling too much behind the the number of entities that ghc can offers.
* By ghc 9.8.2: we are only having:`VarName, DataName, TvName, TcClsName, FldName`.
* While we are having entities(simplified from `TyThing`): `patsyn, class, class method, type syn, type family...`
~~It might be a good idea to expand the namespace to support some more discrete classification as mentioned above. Like what we did with field name, `varName` is refined to `field name` in the rename stage. As a result, It can offer a cheap way to query more accurately what entity the occname refers to, especially combining with #24244 to expose the NameSpace constructor. ~~
The primary motivation is to ease the implementation of our tools and protocols without having to query `tyThing` or `Id`. It is expecially useful for tools are depend only on `HieFile`. Some related issue in HLS https://github.com/haskell/haskell-language-server/issues/4119
Protocols that need this information are:
1. `SymbolKind` in [LSIF](https://microsoft.github.io/language-server-protocol/specifications/lsif/0.6.0/specification/#documentSymbol) for document symbols
2. Semantic token's `tokenTypes` in [LSP](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#semanticTokensLegend) for semantic tokens
3. `Kind` in [scip](https://github.com/sourcegraph/scip/blob/f6c9fe6bf9a86f0bf904451a05fb47e0924818d2/scip.proto#L261)
Some tools for haskell that benefits:
Static-ls, HLS and other tools or library that wish to generate result for the above protocols solely based on `HieFile`.
----------------------------------
After discussion with simon, we probally should take another approach than messing up with namespaces,
create the a new data type for `EntityInfo` from `TyThing` and store it in the `IdentifierDetails` of the `HieFile`. (direct store of `TyThing` is too much).ZubinZubinhttps://gitlab.haskell.org/ghc/ghc/-/issues/24543improve documentation of :doc and -haddock2024-03-19T15:14:03Zjwaldmannimprove documentation of :doc and -haddockI was preaching about `:doc` but people said "what? does not work here".
Of course it works for me since I have ghc option `-haddock` in my global cabal config since forever.
`ghci` does the right thing (it prints `Try re-compiling wi...I was preaching about `:doc` but people said "what? does not work here".
Of course it works for me since I have ghc option `-haddock` in my global cabal config since forever.
`ghci` does the right thing (it prints `Try re-compiling with '-haddock'.`) but GHC documantation feels incomplete:
* documentation for `-haddock` says what is happening (parse Haddock comments and include them in the interface file) but does not say why I should want this https://downloads.haskell.org/ghc/latest/docs/users_guide/using.html#ghc-flag--haddock
* documentation for `:doc` does not say that it needs these interface files, and sounds vague and dated ("experimental, might change with GHC 8.8") https://downloads.haskell.org/ghc/latest/docs/users_guide/ghci.html#ghci-cmd-:doc
(for context, https://club.tidalcycles.org/t/where-are-n-and-notes-documented/5109/8 )
... Can we just make `-haddock` the default in ghc? (I am not sure about implications - interface size and compile time might go up). Global `-haddock` was a bit risky before GHC version 9 (?) since it would occasionally refuse to generate code when a haddock comment was malformed. But I've never seen such an error recently.Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/24541Modify release process to upload to staging area2024-03-13T20:35:02ZBen GamariModify release process to upload to staging areaHistorically we have had problems with users seeing release directories on `downloads.haskell.org` before the release announcement. This can lead to confusion as these artifacts are subject to change and may be incomplete.
Given that we...Historically we have had problems with users seeing release directories on `downloads.haskell.org` before the release announcement. This can lead to confusion as these artifacts are subject to change and may be incomplete.
Given that we have had a few issues along these lines opened during (unfortunately quite prolonged) the 9.10.1-alpha1 release process, I think we need to change the status quo. This will require:
* modifying the release upload scripts to push to a staging area
* modifying the ghc/ghcup-ci> infrastructure pull artifacts from the staging area
* modifying the release process documentation accordinglyBen GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/24540Deserialising `mi_extra_decls` introduces duplication2024-03-20T12:44:05ZHannes SiebenhandlDeserialising `mi_extra_decls` introduces duplication### Summary
When we deserialise `mi_extra_decls` from disk (after compiling with `-fbyte-code-and-object-code` for example), we introduce many duplications of the same `IfaceTyCon`. A two-level census with ghc-debug on the agda code bas...### Summary
When we deserialise `mi_extra_decls` from disk (after compiling with `-fbyte-code-and-object-code` for example), we introduce many duplications of the same `IfaceTyCon`. A two-level census with ghc-debug on the agda code base shows that we have `8_654_045` instances `IfaceTyCon`, or 8.5 million alive.
However, when we look at the actual `IfaceTyCon`s, we can see that a lot of them are duplicates:
```
#ConstrName,#NamePtr,#Element,#UniqueNumberOfElements,#`IfaceTyConInfo`-witnesses
IfaceTyCon,0x77a81438bcb0,351211,1,[0x77a8170abd98]
IfaceTyCon,0x77a81462b308,406823,2,[0x77a8170abd98,0x77a8170abed8]
IfaceTyCon,0x77a814388458,553151,1,[0x77a8170abed8]
IfaceTyCon,0x77a814629180,1685764,1,[0x77a8170abed8]
```
What this essentially means is that we have `1685764` instances of the form `IfaceTyCon 0x77a814629180 0x77a8170abed8` on the heap alive.
In fact, there seem to be at most 6000 unique `IfaceTyCon`s (see the attached data).
We know that we have roughly `200MB` of `IfaceTyCon`s alive:
```
ghc-9.9-inplace:GHC.Iface.Type:IfaceTyCon[ghc-9.9-inplace:GHC.Types.Name:Name,THUNK_1_0]:207697080:8654045:24:24.0
```
Full data: [uniqueIfaceTyCon_sorted.txt](/uploads/20e5af8e65528840fcee017671cead14/uniqueIfaceTyCon_sorted.txt)
### Solutions
Reducing the duplication can be achieved in a number of ways.
One idea is to introduce the deduplication logic to the serialisation of the `ModIface` itself. Similarly to how we deduplicate `Name` and `FastString`, we can think of a `IfaceTyCon` deduplication table. As we don't know yet what data we might want to deduplicate in the future, it would make sense to refactor the serialisation logic of `ModIface` to remove the special logic for `Name` and `FastString` deduplication and replace it with a generic deduplication logic approach. This would allow us to change what we deduplicate without having to rewrite everything whenever we come up with something else to deduplicate. As a positive side effects, this should also noticeably reduce the size of the ModIface on disk.Hannes SiebenhandlHannes Siebenhandlhttps://gitlab.haskell.org/ghc/ghc/-/issues/24539Improve memory efficiency of `UnlinkedBCO`2024-03-20T09:18:31ZHannes SiebenhandlImprove memory efficiency of `UnlinkedBCO`There are quite a number of `UnlinkedBCO`s alive during a GHCi session. For example, loading agda into GHCi, there are around `360050` instances of `UnlinkedBCO`.
Currently `UnlinkedBCO` is defined like this:
```haskell
data UnlinkedBC...There are quite a number of `UnlinkedBCO`s alive during a GHCi session. For example, loading agda into GHCi, there are around `360050` instances of `UnlinkedBCO`.
Currently `UnlinkedBCO` is defined like this:
```haskell
data UnlinkedBCO
= UnlinkedBCO {
unlinkedBCOName :: !Name,
unlinkedBCOArity :: {-# UNPACK #-} !Int,
unlinkedBCOInstrs :: !(UArray Int Word16), -- insns
unlinkedBCOBitmap :: !(UArray Int Word64), -- bitmap
unlinkedBCOLits :: !(SizedSeq BCONPtr), -- non-ptrs
unlinkedBCOPtrs :: !(SizedSeq BCOPtr) -- ptrs
}
```
Saving a couple of Words per `UnlinkedBCO` can quickly accumulate to tens of megabytes.
This issue discusses two improvements that are relatively non-invasive.
### Unpack `UArray Int`
The PR !12142 implements this improvement
The `UArray` of `unlinkedBCOInstrs` and `unlinkedBCOBitmap` is never used, only its packing of `Word16`'s and `Word64`'s is required.
Thus, we can replace `UArray Int Word*` with a wrapper around the underlying `ByteArray#` allowing us to save 6 Ints per `UnlinkedBCO`.
In the example of agda, this saves us roughly `360050 * 6 Ints ~= 17282400 ~ 17MB`. I am unsure whether an `UnliftedNewtype` removes even one more indirection, which would reduce the memory `7MB`.
### Flatten `SizedSeq`
The PR !12170 implements this improvement.
`SizedSeq a` is a simple wrapper around `[a]` that keeps track of the number of elements and supports efficient appending (by keeping the list in reverse).
However, as such, the size is only needed once, and the trivial case of `SizedSeq 0 []` isn't shared. To add insult to injury, lists are quite inefficient, and the `unlinkedBCOLits` and `unlinkedBCOPtrs` are only ever traversed and not filtered or iteratively consumed / constructed.
We show the size distributions of all `SizedSeq`'s, which we obtained using `ghc-debug` scripts:
```
# Length of SizedSeq
283147 0
198237 1
126478 2
69233 3
26596 4
5587 5
3903 6
2943 7
```
The majority of cases is the empty list, singleton and tuple, so this lack of sharing is noticeable. We cut off the end of the table, there are rarely larger lists. I am including the full list for completeness: [unlinkedbco-sseq](/uploads/301ae49a1a2bb3d20e528a6d1b7f0a9d/unlinkedbco-sseq)
Note, not all `SizedSeq`'s are utilised by `UnlinkedBCO`, but most of them:
```
ghc-9.9-inplace:GHC.ByteCode.Types:UnlinkedBCO[ghc-9.9-inplace:GHC.Types.Name:Name,ARR_WORDS,ARR_WORDS,ghc-boot-9.9-inplace:GHC.Data.SizedSeq:SizedSeq,ghc-boot-9.9-inplace:GHC.Data.SizedSeq:SizedSeq]:25923600:360050:72:72.0
ghc-boot-9.9-inplace:GHC.Data.SizedSeq:SizedSeq[ghc-prim:GHC.Types::]:17478120:436953:40:40.0
ghc-boot-9.9-inplace:GHC.Data.SizedSeq:SizedSeq[ghc-prim:GHC.Types:[]]:11325920:283148:40:40.0
```
This says that there are `436953 + 283148 = 720101` SizedSeqs, and `360050 * 2 = 720100` are retained by `UnlinkedBCO`.
Thus, we propose to introduce a new data type that is specialised for this payload, called `FlatBag` which efficiently stores elements and where the empty case can be shared.Hannes SiebenhandlHannes Siebenhandlhttps://gitlab.haskell.org/ghc/ghc/-/issues/24537template-haskell's RecordWildCards support2024-03-25T11:11:54ZLiam Goodacretemplate-haskell's RecordWildCards support## Summary
RecordWildCards syntax `Con {..}` doesn't appear to be represented in template-haskell.
Suppose we have a data type:
```hs
data G = H { field0 :: Int, field1 :: String }
deriving stock Show
```
Using `[e|H {..}|]` yields...## Summary
RecordWildCards syntax `Con {..}` doesn't appear to be represented in template-haskell.
Suppose we have a data type:
```hs
data G = H { field0 :: Int, field1 :: String }
deriving stock Show
```
Using `[e|H {..}|]` yields `RecConE Main.H []`.
But this is indistinguishable from `[e|H {}|]`.
However, using `H {}` in place of `H {..}` won't compile if `H` has fields.
## Expected behavior
Have `RecConE` support wildcards.
### (Solutionising)
Perhaps something like:
```hs
data RecWild = NoRecWildCard | RecWildCard
data Exp ...
| RecConE Name [FieldExp] RecWild
data Pat ...
| RecP Name [FieldPat] RecWild
```
Supporting both `H {..}` and `H {field1=42, ..}`.
Maybe `.Lib` could keep its existing `recConE` & `recP` but add `recConWildE` & `recWildP`? (if that's desirable)
```
recConE :: Quote m => Name -> [m (Name, Exp)] -> m Exp
recConE c fs = do { flds <- sequenceA fs; pure (RecConE c flds NoRecWildCard) }
recConWildE :: Quote m => Name -> [m (Name, Exp)] -> m Exp
recConWildE c fs = do { flds <- sequenceA fs; pure (RecConE c flds RecWildCard) }
```
## Environment
* GHC version used: 9.8.2 and below.https://gitlab.haskell.org/ghc/ghc/-/issues/24535Allow foreign import declarations to be split into type definition and "imple...2024-03-19T15:25:03ZOleg GrenrusAllow foreign import declarations to be split into type definition and "implementation" importInstead of
```haskell
foreign import ccall unsafe "lookup3.h _jenkins_hashword" hashWord
:: Ptr Word32 -> CSize -> Word32 -> IO Word32
```
allow to write
```haskell
hashWord :: Ptr Word32 -> CSize -> Word32 -> IO Word32
foreign im...Instead of
```haskell
foreign import ccall unsafe "lookup3.h _jenkins_hashword" hashWord
:: Ptr Word32 -> CSize -> Word32 -> IO Word32
```
allow to write
```haskell
hashWord :: Ptr Word32 -> CSize -> Word32 -> IO Word32
foreign import ccall unsafe "lookup3.h _jenkins_hashword" hashWord
```
Note: we can get close by
```haskell
foreign import ccall unsafe "lookup3.h _jenkins_hashword"
hashWord :: Ptr Word32 -> CSize -> Word32 -> IO Word32
```
---
The motivation is that sometimes a function is natively implemented, sometimes it's a FFI import (depending on CPP, or through course of the project), and the vastly different syntax for function declaration is not convenient.https://gitlab.haskell.org/ghc/ghc/-/issues/24534Allow foreign imports to return ST actions2024-03-12T15:14:13ZOleg GrenrusAllow foreign imports to return ST actionsSome FFI usage is "pure" in the sense of ST, say you allocate some buffer (`MutableByteArray# s`) and pass it to the C function. I cannot use
```haskell
foreign import ccall "initMyStruct" c_initMyStruct :: MutableByteArray# s -> ST s (...Some FFI usage is "pure" in the sense of ST, say you allocate some buffer (`MutableByteArray# s`) and pass it to the C function. I cannot use
```haskell
foreign import ccall "initMyStruct" c_initMyStruct :: MutableByteArray# s -> ST s ()
```
which is a pity.https://gitlab.haskell.org/ghc/ghc/-/issues/24531Runtime failure on windows with zlib-0.7.0.0 when missing zlib library2024-03-12T15:28:23ZHannes SiebenhandlRuntime failure on windows with zlib-0.7.0.0 when missing zlib libraryFirst reported by https://github.com/haskell/zlib/issues/65
GHC doesn't fail compilation of a binary depending on `zlib-0.7.0.0`, although the linking of the zlib system depedency failed. The issue exists at least on GHC 9.2.8 through G...First reported by https://github.com/haskell/zlib/issues/65
GHC doesn't fail compilation of a binary depending on `zlib-0.7.0.0`, although the linking of the zlib system depedency failed. The issue exists at least on GHC 9.2.8 through GHC 9.6.
There is no message when running `cabal build`, but opening a repl session fails with the message:
```
ghc-9.4.8.exe: Could not load `zlib1.dll'. Reason: addDLL: zlib1.dll or dependencies not loaded. (Win32 error 126)
```
I was able to reproduce the issue on Win 10, GHC 9.4.8 and cabal 3.10.2.1, but was unable to reproduce the issue on any windows GitHub CI runners.
I briefly investigated, the main change seems to be that zlib haskell library switched to using `extra-libraries` on windows, which should alwasy exist as GHC ships with zlib on windows. Likewise, I verified the library exists, too.Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/24528Bump time to 1.142024-03-27T13:44:44ZAshley YakeleyBump time to 1.14I've just released time-1.14 to Hackage. The corresponding git commit is the ghc branch, which always points to the commit that I intend for GHC (and matches the latest release in Hackage).I've just released time-1.14 to Hackage. The corresponding git commit is the ghc branch, which always points to the commit that I intend for GHC (and matches the latest release in Hackage).9.10.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/24524ghc-heap doesn't allow containers 0.72024-03-12T14:43:09ZDavid Feuerghc-heap doesn't allow containers 0.7## Summary
We can't run the `containers` tests with the `containers` version set to 0.7 because `ghc-heap` imposes an upper bound below that.
Optional:
* Operating System:
* System Architecture:## Summary
We can't run the `containers` tests with the `containers` version set to 0.7 because `ghc-heap` imposes an upper bound below that.
Optional:
* Operating System:
* System Architecture:Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/24523`rts-1.0.2.conf` (or earlier) specifies `rts.haddock` but no such file ships ...2024-03-12T14:44:58ZMike Pilgrem`rts-1.0.2.conf` (or earlier) specifies `rts.haddock` but no such file ships with GHC## Summary
Since GHC 9.0.1 (at least, on Windows*), the `rts-1.0.2.conf` file (or its equivalent) has specified a `rts.haddock` file (in key `haddock-interfaces`) but no such file is provided with GHC. Before GHC 9.0.1, the `rts.conf` f...## Summary
Since GHC 9.0.1 (at least, on Windows*), the `rts-1.0.2.conf` file (or its equivalent) has specified a `rts.haddock` file (in key `haddock-interfaces`) but no such file is provided with GHC. Before GHC 9.0.1, the `rts.conf` file did not specify a `*.haddock` file.
*I also looked inside the `*.tar.xz` file for GHC 9.8.2/x86_64/Alpine Linux 3.12 (dynamically linked). I think the same is true for Linux.
## Expected behavior
Either the `*.conf` file does not specify a `*.haddock` file or that the specified `rts.haddock` file is provided with GHC.
## Environment
* GHC version used: 9.0.1 to 9.8.2.
Optional:
* Operating System: Windows
* System Architecture: x86_64ZubinZubinhttps://gitlab.haskell.org/ghc/ghc/-/issues/24520Poor enforcement for importing implicit dependencies2024-03-19T19:10:53ZMatthew Cravenclyring@gmail.comPoor enforcement for importing implicit dependenciesThere are several known-key things that GHC may try to look up the interfaces for during compilation regardless of whether they have been imported. This problematic while bootstrapping, because if we compile a module that tries to refer ...There are several known-key things that GHC may try to look up the interfaces for during compilation regardless of whether they have been imported. This problematic while bootstrapping, because if we compile a module that tries to refer to `GHC.CString.unpackCString#` for string-literal desugaring before `GHC.CString` has been built, compilation will fail.
Two of these potential implicit imports are described in [`Note [Depend on GHC.Num.Integer]` and `Note [Depend on GHC.Tuple]` in `GHC.Internal.Base`](https://gitlab.haskell.org/ghc/ghc/-/blob/38a4b6ab7bbd5e650f43541d091a52ed2655aff6/libraries/ghc-internal/src/GHC/Internal/Base.hs#L351-380), along with our current strategy for managing this problem: Whenever a module X implicitly depends on some known-key thing defined in module Y, the transitive imports of X should include Y. But compliance with this requirement has been inconsistent in practice, leading to issues like #23942 and intermittent CI failures like [this one](https://gitlab.haskell.org/ghc/ghc/-/jobs/1795889) or [this one](https://gitlab.haskell.org/ghc/ghc/-/jobs/1796989).
I do not put blame on the patch authors and reviewers who have recently introduced modules breaking this requirement and thus causing intermittent build errors for everyone: this requirement is obscure and easy to forget. We need an enforcement mechanism, so that mistakes in implicit-dependency imports can be consistently detected _before_ they get merged.
## Solution ideas
1. We could try to explicitly record these implicit dependencies in GHC's down-sweep. This is arguably the _correct_ thing to do. To do this perfectly, we must first identify all potential sources of implicit dependencies before this becomes reliable, and that seems a bit tricky for now.
2. We could add a flag to GHC that causes it to log when-ever it actually tries to read an interface file, then check that the logs generated while building stage 2 are compatible with the dependencies graph used to order building.
3. I am doing some related work in !12179, and the way I smoke-tested my changes to implicit-dependency imports in that patch was by:
* Building a stage-2 compiler in `_build`,
* Reading the various `_build/stage1/**/.dependencies` files to see what hadrian thinks the dependencies are,
* For each output (`*.o` or `*.o-boot`) file X that does not transitively depend on `GHC.Internal.Base`:
* Delete the various `*.o*` and `*.hi*` files in `_build/stage1/`.
* Instruct hadrian to build only X. (If X has an un-tracked implicit dependency, this should fail.)
Why limit the search outputs that don't depend on `GHC.Internal.Base`? Because all _known_ sources of implicit dependencies either
* ...are in the transitive imports of `GHC.Internal`, or
* ...involve `DeriveLift` and can be fixed by re-structuring the `template-haskell` library (#22229), or
* ...involve JS foreign imports/exports with the WASM back-end. (Perhaps this is specific enough to handle with approach 1?)
* ...are not likely to ever be problematic, like using arrow-syntax without transitively importing the `Arrow` typeclass. (It is very hard to solve the `Arrow` constraints this produces when the class and all of its instances are out of scope.)
Since there are only a few dozen modules and boot-modules that do not depend on `GHC.Internal.Base`, I believe the cost of this validation approach should be affordable. And I think it would be relatively easy for one of the CI gurus to automate this approach. But it's definitely a bit of an ugly hack. Option 2 seems much better in the long run. (The smoke-test was still valuable; doing this caught a couple of issues I missed in !12179.)https://gitlab.haskell.org/ghc/ghc/-/issues/24519CmmToAsm/x86: Poor unrolling for unaligned memcpy2024-03-20T14:58:37ZMatthew Cravenclyring@gmail.comCmmToAsm/x86: Poor unrolling for unaligned memcpyCompile the following module, and look at the generated assembly:
```haskell
module Memcpy where
import Foreign
import Data.Word
fun :: Ptr Word8 -> Ptr Word8 -> IO ()
fun p q = copyBytes p q 16
```
When I compile with `ghc-9.8.2 -O ...Compile the following module, and look at the generated assembly:
```haskell
module Memcpy where
import Foreign
import Data.Word
fun :: Ptr Word8 -> Ptr Word8 -> IO ()
fun p q = copyBytes p q 16
```
When I compile with `ghc-9.8.2 -O -dno-typeable-binds Memcpy.hs -S` on my x86-64 machine, this is what I see:
<details>
```asm
.section .text
.align 8
.align 8
.quad 12884901903
.quad 0
.long 14
.long 0
.globl Memcpy_fun1_info
.type Memcpy_fun1_info, @function
Memcpy_fun1_info:
.LcRu:
leaq -16(%rbp),%rax
cmpq %r15,%rax
jb .LcRy
.LcRz:
movq $.LcRr_info,-16(%rbp)
movq %r14,%rbx
movq %rsi,-8(%rbp)
addq $-16,%rbp
testb $7,%bl
jne .LcRr
.LcRs:
jmp *(%rbx)
.align 8
.quad 1
.long 30
.long 0
.LcRr_info:
.LcRr:
movq $.LcRx_info,(%rbp)
movq 7(%rbx),%rax
movq 8(%rbp),%rbx
movq %rax,8(%rbp)
testb $7,%bl
jne .LcRx
.LcRB:
jmp *(%rbx)
.align 8
.quad 65
.long 30
.long 0
.LcRx_info:
.LcRx:
movq 8(%rbp),%rax
movq 7(%rbx),%rbx
;; !!!
movb 0(%rbx),%cl
movb %cl,0(%rax)
movb 1(%rbx),%cl
movb %cl,1(%rax)
movb 2(%rbx),%cl
movb %cl,2(%rax)
movb 3(%rbx),%cl
movb %cl,3(%rax)
movb 4(%rbx),%cl
movb %cl,4(%rax)
movb 5(%rbx),%cl
movb %cl,5(%rax)
movb 6(%rbx),%cl
movb %cl,6(%rax)
movb 7(%rbx),%cl
movb %cl,7(%rax)
movb 8(%rbx),%cl
movb %cl,8(%rax)
movb 9(%rbx),%cl
movb %cl,9(%rax)
movb 10(%rbx),%cl
movb %cl,10(%rax)
movb 11(%rbx),%cl
movb %cl,11(%rax)
movb 12(%rbx),%cl
movb %cl,12(%rax)
movb 13(%rbx),%cl
movb %cl,13(%rax)
movb 14(%rbx),%cl
movb %cl,14(%rax)
movb 15(%rbx),%bl
movb %bl,15(%rax)
leaq ghczmprim_GHCziTupleziPrim_Z0T_closure+1(%rip),%rbx
addq $16,%rbp
jmp *(%rbp)
.LcRy:
leaq Memcpy_fun1_closure(%rip),%rbx
jmp *-8(%r13)
.size Memcpy_fun1_info, .-Memcpy_fun1_info
.section .data
.align 8
.align 1
.globl Memcpy_fun1_closure
.type Memcpy_fun1_closure, @object
Memcpy_fun1_closure:
.quad Memcpy_fun1_info
.section .text
.align 8
.align 8
.quad 12884901903
.quad 0
.long 14
.long 0
.globl Memcpy_fun_info
.type Memcpy_fun_info, @function
Memcpy_fun_info:
.LcRU:
jmp Memcpy_fun1_info
.size Memcpy_fun_info, .-Memcpy_fun_info
.section .data
.align 8
.align 1
.globl Memcpy_fun_closure
.type Memcpy_fun_closure, @object
Memcpy_fun_closure:
.quad Memcpy_fun_info
.section .note.GNU-stack,"",@progbits
.ident "GHC 9.8.2"
```
</details>
Notice the 32 single-byte `movb` instructions used to implement the copy. (I have marked this with `!!!`.)
We are probably using single-byte move instructions because the given `Ptr`s can have arbitrary alignment. But on x86-64, the penalty for an unaligned `movq` is typically at most a few cycles. It would be much better for both speed and code size to emit four eight-byte move instructions or even two unaligned 16-byte move instructions. (There are a few of the latter in SSE and SSE2, which we assume are available on every x86-64 machine.) And indeed I see the latter if I also add `-fllvm`.
I haven't checked, but would not be surprised if there were similar opportunities for improvement available on other platforms.https://gitlab.haskell.org/ghc/ghc/-/issues/24518Update Cabal to version 3.10.3.0 for GHC-9.6 and GHC-9.82024-03-21T13:19:34ZTrevis ElserUpdate Cabal to version 3.10.3.0 for GHC-9.6 and GHC-9.8## Summary
At the most user facing level, plugins appear to not work correctly with 9.6/9.8 when using `stack`. The issue on that side is tracked https://github.com/commercialhaskell/stack/issues/6251. However, it would appear that the ...## Summary
At the most user facing level, plugins appear to not work correctly with 9.6/9.8 when using `stack`. The issue on that side is tracked https://github.com/commercialhaskell/stack/issues/6251. However, it would appear that the underlying issue is with the `Cabal` library. The issue for `Cabal` is at https://github.com/haskell/cabal/issues/9375. The fix for this is included in `cabal-3.10.3.0`~~, which ghc-9.10 appears to be ahead of~~.
So if I'm understanding the various moving parts all correctly bumping the included `Cabal` version for the next 9.6 and 9.8 series releases will fix the issue. As it stands, this is holding some users on 9.4.x.
## Steps to reproduce
From the cabal issue, reproducing would appear to be as simple as having a plugin module Foo and then running:
```
ghc-9.6.3 --abi-hash -fplugin=Foo
```
Which would result in:
```
<command line>: Could not find module ‘Foo’
Use -v (or `:set -v` in ghci) to see a list of the files searched for.
```
## Expected behavior
The expectation would be to have a hash from the above.
@mpickering I'm tagging you because you commented here: https://github.com/haskell/cabal/issues/9375#issuecomment-1789748616 and almost certainly have more context/understanding than I do on the internal implications of this.9.6.5ZubinZubinhttps://gitlab.haskell.org/ghc/ghc/-/issues/24517Provide RTS statistics in GHC.Stats, for example number of blocked threads etc2024-03-14T10:40:51ZliteronProvide RTS statistics in GHC.Stats, for example number of blocked threads etc## Motivation
The current GHC.Stats mainly exposes GC details, and memory usage details. But it doesn't expose anything about number of running/blocked... threads? It can be insightful when troubleshooting production issues to see for e...## Motivation
The current GHC.Stats mainly exposes GC details, and memory usage details. But it doesn't expose anything about number of running/blocked... threads? It can be insightful when troubleshooting production issues to see for example that the number of blocked threads (for example blocked on some MVar / TVar) have suddenly increased.
Now, I have no idea what of this kind of thread/MVar/TVar/.. stats is feasible to collect/expose in the runtime, but the more the merrier.
## Proposal
Basically adding new stats fields about threads or synchronization primitives (STM retry counts, whatever).
Note that these are preferred in a Prometheus-friendly incremental counter format, like many of the memory-related stats already are.https://gitlab.haskell.org/ghc/ghc/-/issues/24514Emit DWARFv52024-03-12T14:57:35ZSophie TaylorEmit DWARFv5The GHC manual states that GHC emits DWARFv4 information. [DWARFv5](https://dwarfstd.org/dwarf5std.html), stabilised in 2017, includes several new features relevant to Haskell:
- Haskell language code
- A new DIE, `DW_TAG_call_site`, and...The GHC manual states that GHC emits DWARFv4 information. [DWARFv5](https://dwarfstd.org/dwarf5std.html), stabilised in 2017, includes several new features relevant to Haskell:
- Haskell language code
- A new DIE, `DW_TAG_call_site`, and related attributes and expressions, which can include tail call and tail recursion information
- A new attribute, `DW_AT_noreturn`, which would be useful for CPS'd code
There is some minor incompatibility between DWARFv4 and DWARFv5, but it's probably worth the effort to greatly increase the quality of the debug information. For starters, it seems that the `DW_TAG_call_site` information could be emitted without having to make the migration changes.
An example of `gdb` support for this is here: https://sourceware.org/gdb/current/onlinedocs/gdb.html/Tail-Call-Frames.htmlhttps://gitlab.haskell.org/ghc/ghc/-/issues/24511GHCI missing new line on Windows WSL 2.0 Debian Environment2024-03-13T00:45:55ZBrian TeagueGHCI missing new line on Windows WSL 2.0 Debian Environment## Summary
Expressions entered in the GHCI REPL interface do not create a newline character after pressing enter before the output is rendered.
```haskell
❯ ghci
GHCi, version 9.8.1: https://www.haskell.org/ghc/ :? for help
ghci> 1 + ...## Summary
Expressions entered in the GHCI REPL interface do not create a newline character after pressing enter before the output is rendered.
```haskell
❯ ghci
GHCi, version 9.8.1: https://www.haskell.org/ghc/ :? for help
ghci> 1 + 12
ghci> double x = x + xghci> double 24
ghci>
```
## Steps to reproduce
* Start Alacritty Terminal version 0.11.0 on windows
* Type command Debian to enter WSL environment
* Type GHCI to start the GHCI interpreter.
* Enter any expression and press enter.
## Expected behavior
Expected the GHCI interpreter to create a new line character after pressing enter before displaying the output
```haskell
❯ ghci
GHCi, version 9.8.1: https://www.haskell.org/ghc/ :? for help
ghci> 1 + 1
2
ghci> double x = x + x
ghci> double 2
4
ghci>
```
## Environment
│✔✔ GHCup 0.1.20.0 latest,recommended
│✔✔ Stack 2.13.1 recommended
│✔✔ HLS 2.5.0.0 recommended
│✔✔ cabal 3.10.2.1 latest,recommended
│✔✔ GHC 9.8.1 base-4.19.0.0 hls-powered,2023-10-09
## Optional:
### Operating System:
* WSL version: 2.0.9.0
* Kernel version: 5.15.133.1-1
* WSL image: Debian
* WSLg version: 1.0.59
* MSRDC version: 1.2.4677
* Direct3D version: 1.611.1-81528511
* DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
* Windows version: 10.0.19045.4046
### System Architecture: X86_64https://gitlab.haskell.org/ghc/ghc/-/issues/24510Generically's mappend should agree with the underlying (<>)2024-03-12T15:03:08ZIcelandjackGenerically's mappend should agree with the underlying (<>)There is unfortunate duplication of behaviours with `(<>)` and `mappend`, their meaning should always coincide but there are ways of making them out of sync. GeneralizedNewtypeDeriving is one way, but I wanted to discuss an error brought...There is unfortunate duplication of behaviours with `(<>)` and `mappend`, their meaning should always coincide but there are ways of making them out of sync. GeneralizedNewtypeDeriving is one way, but I wanted to discuss an error brought to my attention.
```haskell
{-# Language DerivingVia #-}
{-# Language DerivingStrategies #-}
import Data.Monoid
import Data.Map
import GHC.Generics
-- :set -XOverloadedLists
-- >> Foo [('a', "Hello")] `mappend` Foo [('a', "World")]
-- Foo (fromList [('a',"Hello")])
-- >> Foo [('a', "Hello")] <> Foo [('a', "World")]
-- Foo (fromList [('a',"HelloWorld")])
data Foo = Foo (Map Char String)
deriving stock (Show, Generic)
deriving Monoid via Generically Foo
instance Semigroup Foo where
Foo map <> Foo map1 = Foo (unionWith (<>) map map1)
```
The desired append operation is clearly the user-defined one: `unionWith (<>)`, but `Generically Foo` (wrongly) assumes that the user is deriving `Semigroup` generically as well: `(<>) @(Generically Foo)`.
```haskell
instance (Generic a, Monoid (Rep a ()) => Monoid (Generically a) where
..
mappend :: Generically a -> Generically a -> Generically a
mappend = (<>) @(Generically a)
```
Instead, I propose adding a `Semigroup a` constraint and making use of whatever `(<>)` method already exists. If the user derives `(<>)` generically, then `mappend` will also be generic. In this example, where the user has specified their own bespoke `(<>) = unionWith (<>)` that should be used for `mappend`.
We now see that both `mappend` and `(<>)` produce the same result:
```haskell
-- >> Foo [('a', "Hello")] `mappend` Foo [('a', "World")]
-- Foo (fromList [('a',"HelloWorld")])
-- >> Foo [('a', "Hello")] <> Foo [('a', "World")]
-- Foo (fromList [('a',"HelloWorld")])
instance (Generic a, Semigroup a, Monoid (Rep a ()) => Monoid (Generically a) where
..
mappend :: Generically a -> Generically a -> Generically a
mappend = coerce do (<>) @a
```