GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2024-03-20T10:46:50Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/24289Enable documentation building in cross bindists2024-03-20T10:46:50ZMatthew PickeringEnable documentation building in cross bindistsThere appears to be no inherent reason why we can't build documentation in a cross bindists. The hadrian rules currently bake in some incorrect assumptions about stages of libraries we should generate documentation for but these rules ca...There appears to be no inherent reason why we can't build documentation in a cross bindists. The hadrian rules currently bake in some incorrect assumptions about stages of libraries we should generate documentation for but these rules can probably be generalised to allow documentation to be produced for cross bindists.https://gitlab.haskell.org/ghc/ghc/-/issues/21970Cross-compiler binary distribution configure script requires --target flag2024-03-20T10:46:50ZBen GamariCross-compiler binary distribution configure script requires --target flagCurrently when one attempts to install a cross-compiler bindist, one must pass `--target=...` to the bindist `configure`. Ideally the `configure` script would already know the target platform.Currently when one attempts to install a cross-compiler bindist, one must pass `--target=...` to the bindist `configure`. Ideally the `configure` script would already know the target platform.9.10.1https://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/24563IfaceAppArgs has inefficient Binary instance2024-03-20T02:34:47ZMatthew PickeringIfaceAppArgs has inefficient Binary instanceProblem 1: `Binary IfaceAppArgs` has it's own Binary instance which is different to [a] instance. It directly writes the linked list to the interface file rather than writing the length of the list followed by the whole list continuously...Problem 1: `Binary IfaceAppArgs` has it's own Binary instance which is different to [a] instance. It directly writes the linked list to the interface file rather than writing the length of the list followed by the whole list continuously.
In some interface files this leads to 36% of the interface being taken up by these tag bits.
Problem 2: The `ForAllTyFlag` is serialised to interface files but is not used in `tcIfaceType`.
In some interface files these additional bytes make up `19%` of the entire interface file.Hannes SiebenhandlHannes Siebenhandlhttps://gitlab.haskell.org/ghc/ghc/-/issues/24150Non-moving segment allocation strategy might be leading to fragmentation2024-03-19T22:44:50ZTeo CamarasuNon-moving segment allocation strategy might be leading to fragmentation## Summary
I think the current allocation strategy for the non-moving heap might be to unnecessary fragmentation
## Issue
The non-moving heap consists of segments that are aligned and 32K (that's 8 4K blocks).
In order to allocate alig...## Summary
I think the current allocation strategy for the non-moving heap might be to unnecessary fragmentation
## Issue
The non-moving heap consists of segments that are aligned and 32K (that's 8 4K blocks).
In order to allocate aligned blocks we currently allocate `(2*b - 1)` blocks and find the required aligned part and then immediately de-allocate the rest. See: https://gitlab.haskell.org/ghc/ghc/-/blob/ef3d20f83499cf129b1cacac07906b8d6188fc17/rts/sm/BlockAlloc.c#L570
My worry is that this strategy can lead to a situation where the heap ends up with lots of small free block groups (less than 15 blocks) that cannot be used by the allocator to service non-moving segment requests.
For instance, we could have a situation where every second 8 block group is free on a megablock, but we can't allocate into them because we need 15 to guarantee alignment.
In the past, I've found that adding an extra copying generation to a heap that uses the non-moving GC really reduces fragmentation. I think the reason is that it can use these blocks that are otherwise unusable.
I don't have concrete evidence for this yet. I'll try to gather some more data and report back.
My plan is to add some instrumentation that records the sizes of free block groups throughout the lifetime of an application.
## Proposed solution
I think the best thing to do here is to claim entire megablocks for the use of the non-moving heap.
So it would have a list of megablocks with free space. If a megablock ends up completely free then we de-allocate it, but otherwise it would be held on a list by the non-moving gc.
It would probably be good to make this configurable since it might lead to some overhead, since now no other allocation could go into these blocks.
This also requires a bit more book keeping than the current approach.
The advantage is that we could basically eliminate this sort of fragmentation.
## Implementation
If this sounds like a good idea, I'd be happy to implement.Teo CamarasuTeo Camarasuhttps://gitlab.haskell.org/ghc/ghc/-/issues/24556Constant folding integer division2024-03-19T19:51:43ZJannisConstant folding integer division## Summary
In !8392 a question about `minBound / (-1)` for integer division came up and its unboxed primop has different behavior depending on optimizations:
`let I# x = minBound in I# (quotInt# x (-1#)) == floating point exception (-O...## Summary
In !8392 a question about `minBound / (-1)` for integer division came up and its unboxed primop has different behavior depending on optimizations:
`let I# x = minBound in I# (quotInt# x (-1#)) == floating point exception (-O0) or minBound (-O1)`
As far as I can tell this happens in core, but I am pretty sure the cmm constant folding would do the same.
## Expected behavior
Both of them should crash with the floating point exception.
## Environment
* GHC version used: 8.4.4 - 9.8.2
Tested on play.haskell.org for every version available there (8.4.4 - 9.8.2) and locally on some recent version of the main branch.JannisJannishttps://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/17747Allow ByteArray# objects outside of HEAP_ALLOCED()2024-03-19T18:49:58ZDuncan CouttsAllow ByteArray# objects outside of HEAP_ALLOCED()## Motivation
I want to be able to have static `ByteArray#`s, and mmaped files that appear as `ByteArray#`s. Both require byte array heap objects that are not `HEAP_ALLOCED()`.
## Proposal
It appears that the only thing we need to do ...## Motivation
I want to be able to have static `ByteArray#`s, and mmaped files that appear as `ByteArray#`s. Both require byte array heap objects that are not `HEAP_ALLOCED()`.
## Proposal
It appears that the only thing we need to do is to extend `evacuate()` (in `rts/sm/Evac.c`) so that in the `!HEAP_ALLOCED_GC(q)` case it appropriately handles the `ARR_WORDS` closure type.
In `evacuate()`, if `!HEAP_ALLOCED_GC(q)` then it does a case analysis on the object's closure type (`info->type`). It only expects to find a few closure types here. These are the ones expected/allowed to be found outside of the heap. It includes special cases for "static" objects (calling `evacuate_static_object`). However for those heap objects that contain no pointers at all it does nothing:
```
case CONSTR_0_1:
case CONSTR_0_2:
case CONSTR_NOCAF:
/* no need to put these on the static linked list, they don't need
* to be scavenged.
*/
return;
```
I think all we need to do is add `case ARR_WORDS:` to this list, so that byte arrays are also allowed and appropriately ignored.
Does this sound like the only case we would have to adjust?
I intend to provide a MR with a test case.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/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/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/24549'<stdin>: hGetLine: invalid argument' with Unicode input on Windows2024-03-19T14:52:54ZSiyuan Chen'<stdin>: hGetLine: invalid argument' with Unicode input on Windows## Summary
On Windows, when handling Unicode input it would report an error.
Due to the probabilistic nature of this issue and different locales, I have to narrow it as much as possible (see below). Nevertheless, I'm not sure if it can...## Summary
On Windows, when handling Unicode input it would report an error.
Due to the probabilistic nature of this issue and different locales, I have to narrow it as much as possible (see below). Nevertheless, I'm not sure if it can be 100% reproducible on your side.
## Steps to reproduce
Change "Current language for non-Unicode programs:" to "Chinese (Simplified, China)" and don't check "Beta: UTF-8". (It's might be not necessary, but can narrow the problem).
Create a new project (named testunicode).
```
-- Main.hs
module Main where
import System.IO
main :: IO ()
main = do
i_enc <- hGetEncoding stdin
o_enc <- hGetEncoding stdout
e_enc <- hGetEncoding stderr
putStrLn $ show i_enc
putStrLn $ show o_enc
putStrLn $ show e_enc
line <- getLine
putStrLn line
```
Ensure there is only one conhost.exe in your task manager (It might be not necessary, but can narrow the problem).
Open `cmd.exe`, set `PATH` for GHC and cabal (DON'T launch by a `.cmd` script, it might cause to unable to reproduce!)
Ensure console Font is "新宋体" (Note that if you select other Font, there would be no error but another problem occurs... see below)
```
C:\work-pl\haskell\testunicode>chcp
Active code page: 936
C:\work-pl\haskell\testunicode>chcp 65001
Active code page: 65001 (This will clear the console)
C:\work-pl\haskell\testunicode>cabal build
... [2 of 2] Linking ... \\testunicode.exe
$ cabal run
C:\work-pl\haskell\testunicode>cabal run
Just UTF-8
Just UTF-8
Just UTF-8
Фывфыв
testunicode: <stdin>: hGetLine: invalid argument (cannot decode byte sequence starting from 208)
```
If can not reproduce (this might be because your code page defaults to UTF-8), do the following:
```
C:\work-pl\haskell\testunicode>chcp 936
Active code page: 936
C:\work-pl\haskell\testunicode>chcp 65001
Active code page: 65001
C:\work-pl\haskell\testunicode>cabal run
Just UTF-8
Just UTF-8
Just UTF-8
Фывфыв
testunicode: <stdin>: hGetLine: invalid argument (cannot decode byte sequence starting from 208)
```
This should reproduce (DON't close the console window, see below).
It seems like a Windows BUG because sometimes no problem, for example, if you launch the console by a `.cmd` script and console's active code page defaults to UTF-8. However, I don't believe it is a Windows BUG, because some other PL is OK, e.g. Racket.
Even it works perfectly in `io-manager=native` mode.
For example, edit testunicode.cabal and add `ghc-options: -rtsopts`.
```
C:\work-pl\haskell\testunicode>cabal clean
C:\work-pl\haskell\testunicode>cabal build
... [2 of 2] Linking ... \\testunicode.exe
C:\work-pl\haskell\testunicode>cabal run testunicode -- +RTS --io-manager=native
Just UTF-8
Just UTF-8
Just UTF-8
Фывфыв
Фывфыв
```
It works perfectly.
However, the `--io-manager=native` can not work normally in REPL.
```
C:\work-pl\haskell\testunicode>cabal repl testunicode --repl-options="+RTS --io-manager=native"
ghci> main
Just UTF-8
Just UTF-8
Just UTF-8
<----- STUCK HERE!!!
```
Note that this issue is only for input. No problem with output. For example, if Main.hs has no `getLine` and just `putStrLn "Фывфыв"`, it works perfectly.
##### If you select Font "Lucida Console" instead of "新宋体".
Then no error occurs, but show nothing.
```
C:\work-pl\haskell\testunicode>cabal run
Just UTF-8
Just UTF-8
Just UTF-8
Фывфыв
<----- NOTHING!
```
However, the Lucida Console definitely can render "Фывфыв", see https://www.myfonts.com/collections/lucida-console-font-monotype-imaging
Thanks.
Related issues: https://gitlab.haskell.org/ghc/ghc/-/issues/10542 https://gitlab.haskell.org/ghc/ghc/-/issues/18307
## Expected behavior
Handle Unicode input correctly.
## Environment
* GHC version used: 9.8.19.8.3https://gitlab.haskell.org/ghc/ghc/-/issues/24562Hide Language.Haskell.TH.Lib.Internal from hoogle/haddocks2024-03-19T14:42:24ZTeo CamarasuHide Language.Haskell.TH.Lib.Internal from hoogle/haddocksOn this mailing list thread: https://mail.haskell.org/pipermail/ghc-devs/2024-March/021569.html
@yav mentions that it's confusing that identifiers from [`Language.Haskell.TH.Lib.Internal`](https://hackage.haskell.org/package/template-has...On this mailing list thread: https://mail.haskell.org/pipermail/ghc-devs/2024-March/021569.html
@yav mentions that it's confusing that identifiers from [`Language.Haskell.TH.Lib.Internal`](https://hackage.haskell.org/package/template-haskell-2.21.0.0/docs/Language-Haskell-TH-Lib-Internal.html) come up when searching on Hoogle and in Haddocks, especially since they have the same names as identifiers from the user-facing `Language.Haskell.TH.Lib` module.
Perhaps we could hide this module from Hoogle/Haddock to avoid this confusion as this module isn't meant to be user-facing anyway?
I think the right way to do this is to add a `hide` hadddock options pragma to the file.
Alternatively we could just remove the module from `exposed-modules` but that seems like an unnecessary breaking change.
Hackage search[^1] reveals only HList depends on this module in an example. The other references are from `ghc`, `ghc-lib` and `ghc-lib-parser`, so I don't think users depend on it in practice either.
[^1]: https://hackage-search.serokell.io/?q=Language.Haskell.TH.Lib.Internal9.10.1Rodrigo MesquitaRodrigo Mesquitahttps://gitlab.haskell.org/ghc/ghc/-/issues/24564Types should be pretty printed as types, not via IfaceType2024-03-19T14:29:12ZMatthew PickeringTypes should be pretty printed as types, not via IfaceTypeQuite a long time ago there were two pretty printers, one for Types and one for IfaceTypes. These were then combined so that Types are converted to IfaceTypes and then printed out.
* Benefit: There is less code.
However, there are some...Quite a long time ago there were two pretty printers, one for Types and one for IfaceTypes. These were then combined so that Types are converted to IfaceTypes and then printed out.
* Benefit: There is less code.
However, there are some downsides to this approach
* Drawback: It is not very modular, because now types purporting to just be to do with interfaces have to know about user pretty printing flags and other details to do with pretty printing. For example see `IfaceFreeTyVar` in `IfaceType`, just an artifact of the pretty printing.
* Drawback: Information gets accidentally serialised to interface files which bloats interface files (see #24563)
If we are going to take steps to reduce interface file size then it is very important to be very very clear about what is going into interface files. Therefore I think we should revert this change and go back to having two pretty printers. One which prints `Type` for users and error messages, and a simpler on which prints `IfaceType` for debugging.https://gitlab.haskell.org/ghc/ghc/-/issues/23966[RFC] Top-level Configure should do nothing but give Hadrian info2024-03-19T14:12:42ZJohn Ericson[RFC] Top-level Configure should do nothing but give Hadrian info@alt-romes and @bgamari, I think this comports with your `ghc-toolchain` work / is already the plan?
It certainly comports with @hsyl20's work to make Hadrian deal with the `*.cabal.in` files.
Right now we have
```m4sh
AC_CONFIG_HEADE...@alt-romes and @bgamari, I think this comports with your `ghc-toolchain` work / is already the plan?
It certainly comports with @hsyl20's work to make Hadrian deal with the `*.cabal.in` files.
Right now we have
```m4sh
AC_CONFIG_HEADER(mk/config.h)
# This one is manually maintained.
AC_CONFIG_HEADER(compiler/ghc-llvm-version.h)
dnl manually outputted above, for reasons described there.
dnl AC_CONFIG_HEADER(rts/include/ghcversion.h)
...
AC_CONFIG_FILES([mk/system-cxx-std-lib-1.0.conf])
...
AC_CONFIG_FILES(
[ mk/project.mk
hadrian/cfg/system.config
hadrian/ghci-cabal
hadrian/ghci-multi-cabal
hadrian/ghci-stack
docs/users_guide/ghc_config.py
distrib/configure.ac
hadrian/cfg/default.host.target
hadrian/cfg/default.target
])
```
That means we should not have the top-level configure produce these files:
- Compiler proper
- [x] `compiler/ghc-llvm-version.h` !11490
- RTS; #17191 will have the RTS configure script produce these directly
- [x] `mk/config.h` --- #17191 will have the RTS configure script produce this directly
- [x] `rts/include/ghcversion.h` --- #17191 again
- Docs
- [x] `docs/users_guide/ghc_config.py`
- Misc install platform sensative for bindist; should GHC toolchain take care of any of these?
- [ ] `mk/system-cxx-std-lib-1.0.conf`
- [ ] `distrib/configure.ac` -- !12051
- [ ] `mk/project.mk` -- !12051
Note that I do think we should keep the `.in` files so they don't *have* to be built with Hadrian --- I don't want to make it harder to get rid of Hadrian later, I just want to break up and get rid of the top-level configure script more than I want to get rid of Hadrian.https://gitlab.haskell.org/ghc/ghc/-/issues/18927Use `SmallArray#`2024-03-19T10:42:46ZSebastian GrafUse `SmallArray#`I think there are several places in the compiler where lists are the wrong data structure and we are better off using an array, e.g. when storing something for multiple uses, never changing it afterwards.
We have `SmallArray#` in `GHC.E...I think there are several places in the compiler where lists are the wrong data structure and we are better off using an array, e.g. when storing something for multiple uses, never changing it afterwards.
We have `SmallArray#` in `GHC.Exts` and we should use it. The problem is that the only half-way comfortable [API I know of is in `primitive`](https://hackage.haskell.org/package/primitive-0.7.1.0/docs/Data-Primitive-SmallArray.html#t:SmallArray), which isn't a boot package. And even that wrapper is far from a feature-complete API to be usable as a drop-in replacement for lists; I think it's merely a compatibility wrapper offering the same API for GHC < 7.10, where it's backed by an `Array#` (plus it uses `MonadPrim` instead).
So I propose to add our own module `GHC.Data.SmallVec` that offers a few key pure functions for a persistent API around `SmallArray#`. I hope for the following instances:
- A fusing `IsList` instance
- `Functor`+`Foldable`+`Traversable` (maybe even `Applicative`) instance
- an indexing function
- (`Binary`+`Outputable` instance)
That should do.
Ideas where to use `SmallVec` (feel free to add more):
- Product `Demand`s
- Syntax elements, such as `MatchGroup`s
- (basically everything which is a syntax-dependent list and thus constant in length by construction)Sebastian GrafSebastian Grafhttps://gitlab.haskell.org/ghc/ghc/-/issues/24455Allow annotating fields to be lazy even if the module is not using StrictData2024-03-18T19:54:59ZOleg GrenrusAllow annotating fields to be lazy even if the module is not using StrictDataThis comes up when using Template Haskell.
There is no convenient way to say that the field of data field in generated declaration to be explicitly lazy.
The current go to approach is to query whether `StrictData` extension is enabled ...This comes up when using Template Haskell.
There is no convenient way to say that the field of data field in generated declaration to be explicitly lazy.
The current go to approach is to query whether `StrictData` extension is enabled and then generate `data Foo = Foo ~Int ~Char` or `data = Foo Int Char` based on that.
Or maybe library functions like [`normalC`](https://hackage.haskell.org/package/template-haskell-2.21.0.0/docs/Language-Haskell-TH-Lib-Internal.html#v:normalC) or `sourceLazy` should query whether `StrictData` is enabled and just work.
---
Note, that for terms, one can ask people to enable `BangPatterns` so one could generate explicitly banged code like, `let !foo = 2 + 2 in ...`, but there is no extensions to just enable writing `data Foo = Foo ~Int ~Char` without also changing the meaning of `data Foo = Foo Int Char`, i.e. there is no `LazyDataAnnotations`. In my opinion that is design flaw in `StrictData` extension: it bundles syntax *and* changes defaults.https://gitlab.haskell.org/ghc/ghc/-/issues/24179Dead code and compiled file size in Windows2024-03-18T19:43:04ZHai / @BestYeenDead code and compiled file size in WindowsSorry for the free text format of the ticket now, but in this case I'll try to provide sample data if the discussion leads to it instead of upfront.
When I've switched from GHC 8 to GHC 9 for Windows, I've noticed that my .exe files gre...Sorry for the free text format of the ticket now, but in this case I'll try to provide sample data if the discussion leads to it instead of upfront.
When I've switched from GHC 8 to GHC 9 for Windows, I've noticed that my .exe files grew a lot bigger.
At first I thought it had to do with the split-sections problem shown here: https://gitlab.haskell.org/ghc/ghc/-/issues/22834 - but that is now fixed and I'm using GHC 9.6.3, with split-sections again.
Right now, if I make a small sample file that just outputs a string to the console but also uses my own custom prelude, my .exe file is <span dir="">\~</span> 13MB.
If I import my linear algebra module (a .hs file with more dependencies) but don't use anything from it at all, the file size grows to <span dir="">\~</span> 21MB.
I'm compiling as prod/optimized with these settings (Can't use the nonmoving GC via the RTS-opts right now because of https://gitlab.haskell.org/ghc/ghc/-/issues/24042 - that should come with GHC 9.6.4 again):
`@call ghc.exe -Weverything -Wmissing-signatures -Wno-missed-specialisations -Wno-all-missed-specialisations -Wno-implicit-prelude -Wno-missing-deriving-strategies -Wno-missing-fields -Wno-missing-home-modules -Wno-missing-import-lists -Wno-missing-local-signatures -Wno-monomorphism-restriction -Wno-name-shadowing -Wno-orphans -Wno-partial-fields -Wno-safe -Wno-tabs -Wno-unsafe -Wno-prepositive-qualified-module -Wno-missing-safe-haskell-mode -Wno-compat-unqualified-imports -Wno-operator-whitespace -Wno-missing-kind-signatures -XNoImplicitPrelude -I"D:\Projects\Haskell\final\..\headers" -threaded -fno-gen-manifest -optc-ffast-math -optc-fno-ident -split-sections -DWINVER=0x0602 -D_WIN32_WINNT=0x0602 -XBangPatterns -XCApiFFI -XConstrainedClassMethods -XConstraintKinds -XDisambiguateRecordFields -XDuplicateRecordFields -XEmptyCase -XEmptyDataDeriving -XExistentialQuantification -XExplicitForAll -XExplicitNamespaces -XFlexibleContexts -XFlexibleInstances -XForeignFunctionInterface -XFunctionalDependencies -XGADTs -XGADTSyntax -XGeneralizedNewtypeDeriving -XKindSignatures -XLiberalTypeSynonyms -XMagicHash -XMonoLocalBinds -XMultiParamTypeClasses -XNamedFieldPuns -XParallelListComp -XQuantifiedConstraints -XRankNTypes -XScopedTypeVariables -XStandaloneDeriving -XTypeFamilies -XTypeFamilyDependencies -XTypeOperators -XTypeSynonymInstances -XUnboxedSums -XUnboxedTuples -XNoFieldSelectors -O2 -tmpdir "D:\Projects\Haskell\final\..\_temp\ghc-r-temp" -odir "D:\Projects\Haskell\final\..\_temp\ghc-r-o" -hidir "D:\Projects\Haskell\final\..\_temp\ghc-r-hi" "D:\Projects\Haskell\final\t.hs" "t.res.o"`
Before moving on, I'd like to clear up something:
Isn't GHC supposed to remove dead code that it can even warn me about (redundant import)?
Then, after the module level, I'd expect it to detect unused functions, constructs, etc. and remove those too in the intermediate representation before advancing further in the compilation process. In my intuition, Haskell should excel at this kind of flow graph analysis. And if it fails there, split-sections should be able to catch that and make up for it later. (I use this after the compilation: `strip --strip-unneeded --strip-all --remove-section=.comment --remove-section=.note`)
I'm using export lists in my modules, but not import lists for the files that use them because they're too finicky in my programming.
I understand that .exe file size is really a secondary concern with the availability of resources and so on, and support for Windows is a little tricky in the Haskell ecosystem. But at this point it punishes me for having comprehensive code libraries of which I'm using different parts of for different projects, and because my main program more than doubled in size when switching from GHC 8 to 9 (now at <span dir="">\~</span>36MB), I'm concerned.
Have I set up my compilation wrong somehow? I can imagine it has something to do with imported instances (haven't checked that yet), but none of them would be used in my small sample case.
Best regards. :)Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/24391Add hadrian option for rerunning failed test2024-03-18T15:48:31ZJadeAdd hadrian option for rerunning failed testWhen you write a ghc patch and want to create a MR, you'd probably run all tests locally with `hadrian/build -j --freeze1 test`. You might run into a regression, where let's say `T001`, `T002` and `T003` fail.
You write some code to fix ...When you write a ghc patch and want to create a MR, you'd probably run all tests locally with `hadrian/build -j --freeze1 test`. You might run into a regression, where let's say `T001`, `T002` and `T003` fail.
You write some code to fix the regression and now you manually have to copy down `T001`, `T002` and `T003`.
It would be nicer, if hadrian, upon running all tests, created a file `failed_tests` which listed all the tests that previously failed and deletes them, when they pass again. Running them is also made easier with a flag `--only-run-failed` which only runs tests which previously failed.
An example workflow could then look like
```
<write ghc code>
hadrian/build -j test
- tests failed: A, B (failed_tests file has [A, B])
<write code to fix regression A>
hadrian/build -j --only-run-failed
- tests failed: B (failed_tests file has [B])
<fix regression B, adding regression C>
hadrian/build -j --only-run-failed
- all tests passed!
hadrian/build -j
- tests failed: C (failed_tests file has [C])
<fix C>
hadrian/build -j
- all tests passed!
```https://gitlab.haskell.org/ghc/ghc/-/issues/14030Implement the "Derive Lift instances for data types in template-haskell" prop...2024-03-18T14:36:50ZRyan ScottImplement the "Derive Lift instances for data types in template-haskell" proposalBack in September 2015, I [proposed](https://mail.haskell.org/pipermail/libraries/2015-September/026117.html) using the `DeriveLift` extension to, well, derive `Lift` instance for data types in the `template-haskell` library. The proposa...Back in September 2015, I [proposed](https://mail.haskell.org/pipermail/libraries/2015-September/026117.html) using the `DeriveLift` extension to, well, derive `Lift` instance for data types in the `template-haskell` library. The proposal was well received, but I was unable to implement it at the time due to `DeriveLift`'s newness (having only been introduced in GHC 8.0). Now that GHC 8.0 is the oldest version of GHC that we support bootstrapping with, this is no longer an obstacle.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 8.3 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Template Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Implement the \"Derive Lift instances for data types in template-haskell\" proposal","status":"New","operating_system":"","component":"Template Haskell","related":[],"milestone":"8.4.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"Back in September 2015, I [https://mail.haskell.org/pipermail/libraries/2015-September/026117.html proposed] using the `DeriveLift` extension to, well, derive `Lift` instance for data types in the `template-haskell` library. The proposal was well received, but I was unable to implement it at the time due to `DeriveLift`'s newness (having only been introduced in GHC 8.0). Now that GHC 8.0 is the oldest version of GHC that we support bootstrapping with, this is no longer an obstacle.","type_of_failure":"OtherFailure","blocking":[]} -->