GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2022-05-10T14:56:53Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/19031Deprecate the -h profiling flag, in favour of explicitliy choosing -hc or -hT2022-05-10T14:56:53ZMatthew PickeringDeprecate the -h profiling flag, in favour of explicitliy choosing -hc or -hTWhen profiling is turned on `h` means `-hc`. When profiling is turned off, `-h` means `-hT`. This has always caused me confusion, it would be simpler to not have this simple alias at all and make users explicitly choose which profiling m...When profiling is turned on `h` means `-hc`. When profiling is turned off, `-h` means `-hT`. This has always caused me confusion, it would be simpler to not have this simple alias at all and make users explicitly choose which profiling mode they mean.
We can still have a nice error message which tells users to either use `-hc` or `-hT` depending on the RTS way.
Proposal: Deprecate the `-h` flag and tell users to either use `-hc` or `-hT`.https://gitlab.haskell.org/ghc/ghc/-/issues/18963Re-evaluating the "experimental" stability label from Control.Applicative2022-02-28T12:45:33ZHécate MoonlightRe-evaluating the "experimental" stability label from Control.ApplicativeI think it's been high time we gave Control.Applicative the stability it deserves and switch it from "experimental" to "stable".I think it's been high time we gave Control.Applicative the stability it deserves and switch it from "experimental" to "stable".https://gitlab.haskell.org/ghc/ghc/-/issues/18567-Wunused-packages: show unused component2022-02-20T17:14:00ZGesh-Wunused-packages: show unused component## Motivation
`-Wunused-packages` doesn't list packages at component granularity, making it unuseful for local unused packages.
For example, (supposing `test` actually only needs `foo` and not `bar`):
```
library foo
library bar
librar...## Motivation
`-Wunused-packages` doesn't list packages at component granularity, making it unuseful for local unused packages.
For example, (supposing `test` actually only needs `foo` and not `bar`):
```
library foo
library bar
library test
build-depends:
, bar
, foo
```
properly gives as error (with `-Wunused-packages`)
```
Building library 'test' for bug-0.1.0.0..
<no location info>: error: [-Wunused-packages, -Werror=unused-packages]
The following packages were specified via -package or -package-id flags,
but were not needed for compilation:
- bug-0.1.0.0
```
however, that doesn't tell us which of the local `build-depends` is the unnecessary one.
## Proposal
Emit unused packages at component-level granularity, i.e. in the above case we'd have
```
Building library 'test' for bug-0.1.0.0..
<no location info>: error: [-Wunused-packages, -Werror=unused-packages]
The following packages were specified via -package or -package-id flags,
but were not needed for compilation:
- bug:bar-0.1.0.0
```Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/18410Using the OS and Arch sum types from ghc-boot:GHC.Platform in System.Info2021-04-25T05:55:34ZHécate MoonlightUsing the OS and Arch sum types from ghc-boot:GHC.Platform in System.InfoI am opening this ticket to resume the discussion started by @bgamari on https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3607#note_285223 regarding the usage of a proper sum type to represent OS and Architecture identifiers in [`Syst...I am opening this ticket to resume the discussion started by @bgamari on https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3607#note_285223 regarding the usage of a proper sum type to represent OS and Architecture identifiers in [`System.Info`](https://gitlab.haskell.org/ghc/ghc/-/blob/master/libraries/base/System/Info.hs)
As said by @hsyl20, [ghc-boot:GHC.Platform](https://gitlab.haskell.org/ghc/ghc/-/blob/master/libraries/ghc-boot/GHC/Platform.hs#L112) already exports adequate data types to represent those.
The doors are open, please voice your opinion, should you have one.
To be clear, this ticket is not about the immediate deprecation of the `String`-based API, however unfortunate it may be.Hécate MoonlightHécate Moonlighthttps://gitlab.haskell.org/ghc/ghc/-/issues/18392Add haddock option to override googleapis font URL2020-07-03T16:44:10ZIlias TsitsimpisAdd haddock option to override googleapis font URL## Motivation
Haddock produces documents using fonts from the hard-coded URL `https://fonts.googleapis.com/css?family=PT+Sans:400,400i,700`. Having a package downloading something from an external resource every time a user opens the do...## Motivation
Haddock produces documents using fonts from the hard-coded URL `https://fonts.googleapis.com/css?family=PT+Sans:400,400i,700`. Having a package downloading something from an external resource every time a user opens the documentation is considered bad practice in Debian. Lintian (an error reporting tool for Debian packages) produces the following warning:
```
W: privacy-breach-generic [<link rel="stylesheet" type="text/css" href="https://fonts.googleapis.com/css?family=pt+sans:400,400i,700" />] (https://fonts.googleapis.com/css?family=pt+sans:400,400i,700)
```
## Proposal
It would be great to add an option to haddock (just like `--mathjax=URL`) to allow users to override the hard coded fontUrl to something available locally. Debian already packages this font family (`fonts-paratype` package) so we could use that flag to point to them instead of Google.https://gitlab.haskell.org/ghc/ghc/-/issues/18385Write release notes and migration guide for winio2020-10-20T16:59:32ZTamar ChristinaWrite release notes and migration guide for winiowrite the release notes and migration guide for WinIO.write the release notes and migration guide for WinIO.9.0.1Tamar ChristinaTamar Christinahttps://gitlab.haskell.org/ghc/ghc/-/issues/18375Figure out why bytes allocated is so sensitive on 32-bit platforms2021-01-18T11:04:58ZBen GamariFigure out why bytes allocated is so sensitive on 32-bit platformsThe `bytes allocated` metric seems to be much more variable on 32-bit platforms than 64-bit platforms (see, e.g., !3309). This tends to be particularly true in the `haddock.*` tests. Why is this?
Some possible causes include:
* Perhap...The `bytes allocated` metric seems to be much more variable on 32-bit platforms than 64-bit platforms (see, e.g., !3309). This tends to be particularly true in the `haddock.*` tests. Why is this?
Some possible causes include:
* Perhaps we are seeing overflow due to a 32-bit accumulator or difference somewhere in the accounting codepath?
* The fact that pointers are larger on 64-bit platforms mean that objects are larger; that being said, we track *relative* metric changes, so this should in principle not matter
* On 64-bit platforms we use the two-step allocator; however, it's hard to imagine how this would affect `bytes allocated`. Moreover, we would also expect to see these fluctuations on Windows, where we didn't use two-step reservation until recently.Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/18282Code size and compile time regression in GHC 8.10.12021-05-21T08:47:51ZAlexis KingCode size and compile time regression in GHC 8.10.1This program triggers a significant code size regression in GHC 8.10.1:
```haskell
module M
( mkB2
) where
import Control.Monad.Reader
import Data.Maybe
data A1 = A1 (Maybe String) (Maybe String) (Maybe String) (Maybe String)
data...This program triggers a significant code size regression in GHC 8.10.1:
```haskell
module M
( mkB2
) where
import Control.Monad.Reader
import Data.Maybe
data A1 = A1 (Maybe String) (Maybe String) (Maybe String) (Maybe String)
data A2 = A2 A1 (Maybe String) (Maybe String) (Maybe String) (Maybe String)
(Maybe String) (Maybe String) (Maybe String) (Maybe String)
data B1 = B1 !String !String !String !String
data B2 = B2 !B1 !String !String !String !String !String !String !String !String
type M a = ReaderT [(String, String)] (Either String) a
resolve :: Maybe String -> String -> M (Maybe String)
resolve (Just x) _ = pure (Just x)
resolve Nothing v = asks $ lookup v
mkB1 :: A1 -> M B1
mkB1 (A1 a b c d) = do
a' <- fromMaybe "" <$> resolve a "A"
b' <- fromMaybe "" <$> resolve b "B"
c' <- fromMaybe "" <$> resolve c "C"
d' <- fromMaybe "" <$> resolve d "D"
pure $ B1 a' b' c' d'
mkB2 :: A2 -> M B2
mkB2 (A2 a b c d e f g h i) = do
a' <- mkB1 a
b' <- fromMaybe "db" <$> resolve b "B"
c' <- fromMaybe "dc" <$> resolve c "C"
d' <- fromMaybe "dd" <$> resolve d "D"
e' <- fromMaybe "de" <$> resolve e "E"
f' <- fromMaybe "df" <$> resolve f "F"
g' <- fromMaybe "dg" <$> resolve g "G"
h' <- fromMaybe "dh" <$> resolve h "H"
i' <- fromMaybe "di" <$> resolve i "I"
pure $ B2 a' b' c' d' e' f' g' h' i'
```
The above program is obviously contrived, but it is reduced from a real module in our production codebase. When compiling with `-O -dshow-passes` on GHC 8.8.2, compile times are quick and code size is small, as expected:
```
*** CoreTidy [M]:
Result size of Tidy Core
= {terms: 812, types: 510, coercions: 11, joins: 21/21}
!!! CoreTidy [M]: finished in 2.23 milliseconds, allocated 2.792 megabytes
*** CorePrep [M]:
Result size of CorePrep
= {terms: 910, types: 636, coercions: 11, joins: 21/38}
!!! CorePrep [M]: finished in 0.80 milliseconds, allocated 1.360 megabytes
*** Stg2Stg:
*** CodeGen [M]:
!!! CodeGen [M]: finished in 40.30 milliseconds, allocated 38.977 megabytes
```
But when compiled with the same options on GHC 8.10.1, compilation time balloons to *over 50 seconds*, and code size is increased by almost two orders of magnitude:
```
*** CoreTidy [M]:
Result size of Tidy Core
= {terms: 72,443, types: 29,596, coercions: 11, joins: 76/76}
!!! CoreTidy [M]: finished in 76.98 milliseconds, allocated 49.157 megabytes
*** CorePrep [M]:
Result size of CorePrep
= {terms: 78,293, types: 32,598, coercions: 11, joins: 76/2,969}
!!! CorePrep [M]: finished in 138.54 milliseconds, allocated 113.637 megabytes
*** Stg2Stg:
*** CodeGen [M]:
!!! CodeGen [M]: finished in 42737.61 milliseconds, allocated 25293.499 megabytes
```
This appears to happen because GHC is duplicating too much code when performing case-of-case simplifications, but I am not certain what the root cause is.
Draft fix in !3426https://gitlab.haskell.org/ghc/ghc/-/issues/18067GHC should inline divInt#2021-04-30T08:41:29ZAndreas KlebingerGHC should inline divInt### Motivation
Currently divInt# is marked as `{-# NOINLINE [0] modInt# #-}`
This can lead to horrible situations where we get (in STG) a division by a constant:
`case GHC.Classes.divInt# sat_shZP 3# of ww7_shZQ`
Since it's a call we ...## Motivation
Currently divInt# is marked as `{-# NOINLINE [0] modInt# #-}`
This can lead to horrible situations where we get (in STG) a division by a constant:
`case GHC.Classes.divInt# sat_shZP 3# of ww7_shZQ`
Since it's a call we need to do some spilling first (in Cmm):
```
cmCK: // global
I64[Sp - 48] = cmCI;
_sm3W::I64 = R3;
R3 = 3;
_sm3V::I64 = R2;
R2 = I64[Sp + 8] + 2;
I64[Sp - 40] = _sm3V::I64;
I64[Sp - 32] = _sm3W::I64;
P64[Sp - 24] = R4;
I64[Sp - 16] = R5;
P64[Sp - 8] = R6;
Sp = Sp - 48;
call GHC.Classes.divInt#_info(R3,
R2) returns to cmCI, args: 8, res: 8, upd: 8;
```
Which adds a fair bit over overhead at the ASM level.
```
movq $block_ciGt_info,-48(%rbp)
movq %rsi,%rax
movl $3,%esi
movq 8(%rbp),%rbx
movq %r14,%rcx
leaq 2(%rbx),%r14
movq %rcx,-40(%rbp)
movq %rax,-32(%rbp)
movq %rdi,-24(%rbp)
movq %r8,-16(%rbp)
movq %r9,-8(%rbp)
addq $-48,%rbp
jmp GHC.Classes.divInt#_info
```
When then execute divInt#
```
x# `divInt#` y#
-- Be careful NOT to overflow if we do any additional arithmetic
-- on the arguments... the following previous version of this
-- code has problems with overflow:
-- | (x# ># 0#) && (y# <# 0#) = ((x# -# y#) -# 1#) `quotInt#` y#
-- | (x# <# 0#) && (y# ># 0#) = ((x# -# y#) +# 1#) `quotInt#` y#
= if isTrue# (x# ># 0#) && isTrue# (y# <# 0#) then ((x# -# 1#) `quotInt#` y#) -# 1#
else if isTrue# (x# <# 0#) && isTrue# (y# ># 0#) then ((x# +# 1#) `quotInt#` y#) -# 1#
else x# `quotInt#` y#
```
## Proposal
`divInt` should probably be marked as INLINE [0] instead.
This would allow *all* of the overhead above to be constant folded away just leaving quotInt#, which I think compiles to a single instruction.https://gitlab.haskell.org/ghc/ghc/-/issues/18060:info (->) inconsistent: Requires -> to be parenthesized but not <->2021-01-20T09:50:28ZIcelandjack:info (->) inconsistent: Requires -> to be parenthesized but not <->## Summary
`:info` for the function arrow requires parentheses `:info (->)`
```haskell
$ devbug
GHCi, version 8.11.0.20200403: https://www.haskell.org/ghc/ :? for help
Prelude>
Prelude> :i ->
<interactive>:1:1: error: parse error on ...## Summary
`:info` for the function arrow requires parentheses `:info (->)`
```haskell
$ devbug
GHCi, version 8.11.0.20200403: https://www.haskell.org/ghc/ :? for help
Prelude>
Prelude> :i ->
<interactive>:1:1: error: parse error on input `->'
Prelude>
Prelude> :i (->)
type (->) :: * -> * -> *
data (->) a b
-- Defined in `GHC.Prim'
infixr -1 ->
instance Applicative ((->) r) -- Defined in `GHC.Base'
instance Functor ((->) r) -- Defined in `GHC.Base'
instance Monad ((->) r) -- Defined in `GHC.Base'
instance Monoid b => Monoid (a -> b) -- Defined in `GHC.Base'
instance Semigroup b => Semigroup (a -> b) -- Defined in `GHC.Base'
Prelude>
Prelude>
```
For any other "type operator" it doesn't matter
```haskell
Prelude> :set -XTypeOperators
Prelude> data a <-> b = Iso (a->b) (b->a)
Prelude> :i <->
type (<->) :: * -> * -> *
data (<->) a b = Iso (a -> b) (b -> a)
-- Defined at <interactive>:3:1
Prelude> :i (<->)
type (<->) :: * -> * -> *
data (<->) a b = Iso (a -> b) (b -> a)
-- Defined at <interactive>:3:1
```
## Expected behavior
`:info ->` should work just as `:info <->` does.
## Environment
* GHC version used: 8.11.0.202004039.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/17969The haddocks for `sortWith` should give guidance about when it's prefered ove...2024-01-21T12:06:26ZAndreas KlebingerThe haddocks for `sortWith` should give guidance about when it's prefered over `sortOn`As ben explained it somewhere else:
> In general if the mapping function is expensive to compute then you should probably be using `sortOn`, as it only needs to compute it once for each element. `sortWith`, on the other hand must comput...As ben explained it somewhere else:
> In general if the mapping function is expensive to compute then you should probably be using `sortOn`, as it only needs to compute it once for each element. `sortWith`, on the other hand must compute the mapping function for every comparison that it performs. Beyond that general intuition it's hard to give any specific prescription.
I think even without more specific guidance stating this much in the docs would be good.⊥https://gitlab.haskell.org/ghc/ghc/-/issues/17928Doctests in base2021-06-09T08:09:15ZHécate MoonlightDoctests in baseI would like to renew the effort to improve the documentation of `base` and, through that, include more doctests in the haddocks.
Some usage of `doctest` can already be seen in [Data.Maybe][maybe] and [Data.Functor][functor]. I would lik...I would like to renew the effort to improve the documentation of `base` and, through that, include more doctests in the haddocks.
Some usage of `doctest` can already be seen in [Data.Maybe][maybe] and [Data.Functor][functor]. I would like to spread its usage to the rest of base.
Being new to the GHC development world, I would love to have your opinion on the matter.
Cheers.
[maybe]: https://gitlab.haskell.org/ghc/ghc/blob/master/libraries%2Fbase%2FData%2FMaybe.hs#L37
[functor]: https://gitlab.haskell.org/ghc/ghc/blob/master/libraries%2Fbase%2FData%2FFunctor.hs#L21
cc @carter, @bgamari, @phadejhttps://gitlab.haskell.org/ghc/ghc/-/issues/17816TH constraint solver change will break significant portions of Hackage.2021-01-25T16:33:14ZMerijn VerstraatenTH constraint solver change will break significant portions of Hackage.I already commented on the original issue, but @osa1 pointed out comments on closed issues tend to get lost.
https://gitlab.haskell.org/ghc/ghc/merge_requests/1817 changes the way the solver deals with top-level splices, but I don't thi...I already commented on the original issue, but @osa1 pointed out comments on closed issues tend to get lost.
https://gitlab.haskell.org/ghc/ghc/merge_requests/1817 changes the way the solver deals with top-level splices, but I don't think the problem this change fixes outweighs the pain GHC 8.10 will inflict on hackage. It is incredibly common to write
```
data Foo = ...
makeLenses ''Foo
```
This keeps the TH call nice and close to the datatype it deals with, but with this change any classes defined below the makeLenses call will be invisible to all the code above, and vice versa. Given how incredibly common this pattern is in most code using TH to generate lenses (which is probably most code that uses lenses) this change will force ~~significant~~ portions of Hackage to gratuitously refactor modules to accommodate this change.
Given how much adoption of 8.8 is already lagging due to the breakage inflicted by `MonadFail`, inflicting yet another massively breaking compiler on Hackage seems unwise.9.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/17686Sort out "bytes allocated" runtime metric fluctuations in compiler2021-10-01T23:45:31ZÖmer Sinan AğacanSort out "bytes allocated" runtime metric fluctuations in compilerCurrently we need to tweak compiler perf test results constantly because of
fluctuation in "bytes allocated" metric. Examples:
- d46a72e19e1b508358827e7270139f3273915697 is a comments-only change that
updates perf numbers of 8 tests
-...Currently we need to tweak compiler perf test results constantly because of
fluctuation in "bytes allocated" metric. Examples:
- d46a72e19e1b508358827e7270139f3273915697 is a comments-only change that
updates perf numbers of 8 tests
- !1747 is a change in compacting GC (the only change is in `Compact.c`) that
causes different "bytes allocated" in compiler perf tests. On CI compiler
allocates more than before, locally I observe that it allocates less than
before. This change should not effect mutators at all and "bytes allocated"
should remain the same.
- https://gitlab.haskell.org/ghc/ghc/-/merge_requests/2842#note_261785 (8822bbc170c2d6779d7c66d6f1aea1bc967babd7) suffers from a commit landing on master that apparently improved some tests (like `T5837`), so that all folowing commits regress again.
- (add more here)
We should find out why the numbers are changing in compiler itself and fix it.
Some related issues:
- #17654 shows that same invocation of GHC results in different "bytes
allocated" numbers
- #8611 a nofib program with changing allocations in each run.
- #16065 stack squeezing in context switch causing different "bytes allocated"
numbers
Some ideas:
- Try `-V0` (disables timer, makes context switches more deterministic)
- Try `-Z` (disables stack squeezing on context switch, see [this][1] for how
this effects allocations)
- Account for stack space (or more generally, RTS allocations) separately from
mutator allocations.
[1]: https://gitlab.haskell.org/ghc/ghc/issues/16065#note_165427https://gitlab.haskell.org/ghc/ghc/-/issues/17643-ddump-simpl prints type applications with trailing whitespace2020-01-08T11:49:12ZRyan Scott-ddump-simpl prints type applications with trailing whitespaceIf you compile the following code with `-ddump-simpl` enabled:
```hs
{-# LANGUAGE TypeApplications #-}
true :: Bool
true = id @Bool True
```
You'll get something like this:
```hs
-- RHS size: {terms: 2, types: 1, coercions: 0, joins:...If you compile the following code with `-ddump-simpl` enabled:
```hs
{-# LANGUAGE TypeApplications #-}
true :: Bool
true = id @Bool True
```
You'll get something like this:
```hs
-- RHS size: {terms: 2, types: 1, coercions: 0, joins: 0/0}
true :: Bool
true = id @ Bool True
```
There's one key difference between the original code and the dumped Core: the latter puts an extra space between the `@` and `Bool`, whereas the former does not. This used to be just a minor curiosity, but now that [GHC Proposal 229](https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0229-whitespace-bang-patterns.rst) is implemented, `id @ Bool True` is no longer code that will even parse correctly.
Granted, Core is not exactly the same as source Haskell, but the `@` syntax in Core has enough similarities to source Haskell's `TypeApplications` that it seems reasonable that we should try to make the two notations coincide. In light of this, I propose that we change `-ddump-simpl`'s pretty-printer to display `true` like this:
```hs
-- RHS size: {terms: 2, types: 1, coercions: 0, joins: 0/0}
true :: Bool
true = id @Bool True
```
That is, do not put any space between the `@` and `Bool`, just as `TypeApplications` now requires. Does this sound like a reasonable suggestion?https://gitlab.haskell.org/ghc/ghc/-/issues/17633Closed type family declaration accepts any name in LHS2020-01-03T21:33:08ZMaxim KoltsovClosed type family declaration accepts any name in LHS## Summary
Closed type family declaration will accept (almost) any name instead of family's name left of `=`.
## Steps to reproduce
```haskell
{-# LANGUAGE TypeFamilies #-}
module WTF where
type family Bar (a :: *) :: * where
Bar ...## Summary
Closed type family declaration will accept (almost) any name instead of family's name left of `=`.
## Steps to reproduce
```haskell
{-# LANGUAGE TypeFamilies #-}
module WTF where
type family Bar (a :: *) :: * where
Bar Int = ()
type family Foo (a :: *) :: * where
Bar Int = Bool
Bar Bool = Int
Bar a = a
```
When loaded to ghci, this file not only compiles, but works as if `Foo` were defined the normal way:
```
λ> :kind! Bar Int
Bar Int :: *
= ()
λ> :kind! Bar Bool
Bar Bool :: *
= Bar Bool
λ> :kind! Foo Int
Foo Int :: *
= Bool
λ> :kind! Foo Bool
Foo Bool :: *
= Int
λ> :kind! Foo Char
Foo Char :: *
= Char
```
It's clear that `Foo` is defined as it should be and that `Bar` is not broken by this definition.
## Expected behavior
GHC should emit an error in this case, as this code seems very strange.
Curiously, if `Bar` is not in scope GHC detects an error at `Foo`'s definition:
```
<interactive>:5:3: error:
Not in scope: type constructor or class ‘Bar’
```
Moreover, if I try to use some family from another module, it fails as well:
```
> import GHC.Generics
> :{
| type family Foo (a :: *) where
| Rep Bool = Maybe
| :}
<interactive>:6:3: error:
• Mismatched type name in type family instance.
Expected: Foo
Actual: Rep
```
## Environment
* GHC version used:
```console
$ stack exec -- ghc -V
The Glorious Glasgow Haskell Compilation System, version 8.6.3
```
* Operating System: macOS8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/17549GHCi can't evaluate expressions with a broken Main module2020-02-19T01:49:52ZNeil MitchellGHCi can't evaluate expressions with a broken Main module## Summary
Using GHC 8.2 and below, if you are in `ghci` with module `Main` loaded, and reload with a broken file, the old module remains in scope. In GHC 8.4 and above, the module no longer works.
## Steps to reproduce
1) Create a fi...## Summary
Using GHC 8.2 and below, if you are in `ghci` with module `Main` loaded, and reload with a broken file, the old module remains in scope. In GHC 8.4 and above, the module no longer works.
## Steps to reproduce
1) Create a file `bug.hs` which is empty
2) Run `ghci bug.hs`
3) Change `bug.hs` to read `import`
4) Type `:reload` in ghci, it displays a message about a parse error
5) Type `1` in ghci, it displays a message about not being able to find module `Main`
## Expected behavior
In GHC 8.2 and below the final step 5 prints out `1`. If you change it to read `impor` then it works. It seems to be only if the module has enough of a header to guess the module name then it results in a prompt where the failed load breaks all subsequent commands. It would be nice if a failed load happens then things remain in a working state.
## Impact
This bug was reported via `ghcid`: https://github.com/ndmitchell/ghcid/issues/290. The `ghcid` program sends a `:reload` followed by `putStrLn "done"` and waits for the `done` to appear. In most circumstances that works. In the above case it doesn't.
Note that if `ghci` could be persuaded to print something on both stdout and stderr (so I know both streams are finished), then `ghcid` wouldn't use `putStrLn`.Roland SennRoland Sennhttps://gitlab.haskell.org/ghc/ghc/-/issues/17497Compress certain IdInfo fields into a single Word642020-05-14T13:47:05ZAndreas KlebingerCompress certain IdInfo fields into a single Word64## Motivation
IdInfos are an absolute massive part of GHC's residency during compilation. Contributing a bit over 15% of residency during it's peak and over 10% over much of the pipeline.
![image](/uploads/2e4fad4b8e7d4c89f5f8877c5a5fc0...## Motivation
IdInfos are an absolute massive part of GHC's residency during compilation. Contributing a bit over 15% of residency during it's peak and over 10% over much of the pipeline.
![image](/uploads/2e4fad4b8e7d4c89f5f8877c5a5fc0d9/image.png)
So reducing it's size by 1/3rd would reduce GHC's footprint by 5% at it's peak with no other changes.
I assume they are also a significant contributor to compiler allocations, so compacting these fields would be beneficial there as well. But maybe not as much so as with residency.
## Proposal
Currently IdInfo is implemented like this:
```haskell
data IdInfo
= IdInfo {
arityInfo :: !ArityInfo, -- ^ 'Id' arity
ruleInfo :: RuleInfo, -- ^ Specialisations of the 'Id's function which exist
-- See Note [Specialisations and RULES in IdInfo]
unfoldingInfo :: Unfolding, -- ^ The 'Id's unfolding
cafInfo :: CafInfo, -- ^ 'Id' CAF info
oneShotInfo :: OneShotInfo, -- ^ Info about a lambda-bound variable, if the 'Id' is one
inlinePragInfo :: InlinePragma, -- ^ Any inline pragma atached to the 'Id'
occInfo :: OccInfo, -- ^ How the 'Id' occurs in the program
strictnessInfo :: StrictSig, -- ^ A strictness signature
demandInfo :: Demand, -- ^ ID demand information
callArityInfo :: !ArityInfo, -- ^ How this is called.
-- n <=> all calls have at least n arguments
levityInfo :: LevityInfo -- ^ when applied, will this Id ever have a levity-polymorphic type?
}
```
Nothing is wrong about that but it's not ideal.
In particular the fields arityInfo, cafInfo, oneShotInfo, callArityInfo and levityInfo could all be compressed into a single Word64 bitmask (if we are content with a max arity of 32k) reducing the size of IdInfo from 12 Words to 8 Words.
So the type would be something like this:
```haskell
data IdInfo
= IdInfo {
ruleInfo :: RuleInfo, -- ^ Specialisations of the 'Id's function which exist
-- See Note [Specialisations and RULES in IdInfo]
unfoldingInfo :: Unfolding, -- ^ The 'Id's unfolding
inlinePragInfo :: InlinePragma, -- ^ Any inline pragma atached to the 'Id'
occInfo :: OccInfo, -- ^ How the 'Id' occurs in the program
strictnessInfo :: StrictSig, -- ^ A strictness signature
demandInfo :: Demand, -- ^ ID demand information
-- n <=> all calls have at least n arguments
bitField :: BitField64 -- ^ Encodes arities, oneShotInfo, cafInfo and levityInfo.
}
newtype BitField64 = BitField64 Word64
-- Functions to extract the values from the bitfield
callArityInfo :: BitField -> !ArityInfo
arityInfo :: ...
...
```
## Problems
* Not all of these fields are strict. It's likely that making them strict would outweigh in order to shrink IdInfo would still be worthwhile. But there might be issues lurking there I did not account for.
* Code churn. These fields are used in many places, as such the diff would be fairly substantial. However using pattern synonyms and other tricks I don't think code using the actual values would look much different, if at all.
* Somebody needs to implement it. I don't plan to in the near future.https://gitlab.haskell.org/ghc/ghc/-/issues/17420Poor error message with DuplicateRecordFields import2022-08-16T12:37:09ZKrzysztof GogolewskiPoor error message with DuplicateRecordFields importGiven the following two files:
```
{-# LANGUAGE DuplicateRecordFields #-}
module X where
data Dog = Dog { name::String }
data Human = Human { name::Int }
```
```
{-# LANGUAGE DuplicateRecordFields #-}
module Y where
import X
foo = u...Given the following two files:
```
{-# LANGUAGE DuplicateRecordFields #-}
module X where
data Dog = Dog { name::String }
data Human = Human { name::Int }
```
```
{-# LANGUAGE DuplicateRecordFields #-}
module Y where
import X
foo = undefined name
```
If we try to compile Y.hs *twice*, we get first:
```
[1 of 2] Compiling X ( X.hs, X.o )
[2 of 2] Compiling Y ( Y.hs, Y.o )
Y.hs:6:17: error:
Ambiguous occurrence ‘name’
It could refer to
either the field ‘name’,
imported from ‘X’ at Y.hs:4:1-8
(and originally defined at X.hs:5:22-25)
or the field ‘name’,
imported from ‘X’ at Y.hs:4:1-8
(and originally defined at X.hs:4:18-21)
```
and then:
```
[2 of 2] Compiling Y ( Y.hs, Y.o )
Y.hs:6:17: error:
Ambiguous occurrence ‘name’
It could refer to
either the field ‘name’, imported from ‘X’ at Y.hs:4:1-8
or the field ‘name’, imported from ‘X’ at Y.hs:4:1-8
|
6 | foo = undefined name
| ^^^^
```
The second error apparently refers to the same thing twice.
Proposed solution: change the error to:
```
either the field ‘name’ of record `Dog`, imported from ‘X’ at Y.hs:4:1-8
or the field ‘name’ of record `Human`, imported from ‘X’ at Y.hs:4:1-8
```https://gitlab.haskell.org/ghc/ghc/-/issues/17411Provide RTS option to return memory non-lazily to the OS on Linux2020-04-02T17:27:59ZNiklas Hambüchenmail@nh2.meProvide RTS option to return memory non-lazily to the OS on Linux## Motivation
On Linux GHC returns memory to the OS by calling `madvise(MADV_FREE)` on pages it no longer needs.
As per `madvise` man page, this returns memory "lazily" -- only under memory pressure does Linux actually adjust the resid...## Motivation
On Linux GHC returns memory to the OS by calling `madvise(MADV_FREE)` on pages it no longer needs.
As per `madvise` man page, this returns memory "lazily" -- only under memory pressure does Linux actually adjust the resident memory (`RSS`) of the process.
That is faster than prompt adjustments, but results high `RSS` numbers being shown in programs like `top`, `htop` and so on, even though GHC has already freed that memory. That can result in end users wrongly complaining about high memory usage, and make investigating memory usage trickier.
#### By the way
The amount of "memory to be lazily freed" can be observed in `/proc/PID/smaps`, with the `LazyFree` field. For example: `grep LazyFree /proc/8429/smaps | grep -v '0 kB'`. @nh2 made himself an `ekg` field to track it, in case you ever need too.
## Proposal
Keep the current default, but add an RTS flag that switches to `MADV_DONTNEED` instead of `MADV_FREE` instead, which will result in prompt `RSS` adjustment. Do this only on Linux.
Go did did this in https://github.com/golang/go/issues/28466.