GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:40:03Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/9550Add uncons to Data.List2019-07-07T18:40:03ZDavid FeuerAdd uncons to Data.ListThis was [discussed on the libraries list](http://www.haskell.org/pipermail/libraries/2014-July/023314.html) and favourably receivedThis was [discussed on the libraries list](http://www.haskell.org/pipermail/libraries/2014-July/023314.html) and favourably received7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9540words is not a good producer; unwords is not a good consumer2019-07-07T18:40:06ZDavid Feuerwords is not a good producer; unwords is not a good consumerI think we can do something like this, once we've fixed `unfoldr`:
```hs
unwords = unfoldr go
where
go [] = Nothing
go ("":ws) = Just (' ', ws)
go ((l:ls):ws) = Just (l, ls:ws)
```
With my draft `unfoldr`, GHC turns this ...I think we can do something like this, once we've fixed `unfoldr`:
```hs
unwords = unfoldr go
where
go [] = Nothing
go ("":ws) = Just (' ', ws)
go ((l:ls):ws) = Just (l, ls:ws)
```
With my draft `unfoldr`, GHC turns this into
```hs
lvl_r1EN
lvl_r1EN = C# ' '
Rec {
unwords_$sgo
unwords_$sgo =
\ sc_s1Gx sc1_s1Gy ->
case sc_s1Gx of _ {
[] -> : lvl_r1EN (unwords_go sc1_s1Gy);
: l_a1Ew ls_a1Ex -> : l_a1Ew (unwords_$sgo ls_a1Ex sc1_s1Gy)
}
unwords_go
unwords_go =
\ b1_a1Fb ->
case b1_a1Fb of _ {
[] -> [];
: ds_d1F5 ws_a1Ev ->
case ds_d1F5 of _ {
[] -> : lvl_r1EN (unwords_go ws_a1Ev);
: l_a1Ew ls_a1Ex -> : l_a1Ew (unwords_$sgo ls_a1Ex ws_a1Ev)
}
}
end Rec }
unwords
unwords = \ b'_a1F9 -> unwords_go b'_a1F9
```
To my untrained eye, that looks pretty reasonable.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.9 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"unwords is not a good producer","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.9","keywords":["fusion"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I think we can do something like this, once we've fixed `unfoldr`:\r\n\r\n{{{#!hs\r\nunwords = unfoldr go\r\n where\r\n go [] = Nothing\r\n go (\"\":ws) = Just (' ', ws)\r\n go ((l:ls):ws) = Just (l, ls:ws)\r\n}}}\r\n\r\nWith my draft `unfoldr`, GHC turns this into\r\n\r\n{{{#!hs\r\nlvl_r1EN\r\nlvl_r1EN = C# ' '\r\n\r\nRec {\r\nunwords_$sgo\r\nunwords_$sgo =\r\n \\ sc_s1Gx sc1_s1Gy ->\r\n case sc_s1Gx of _ {\r\n [] -> : lvl_r1EN (unwords_go sc1_s1Gy);\r\n : l_a1Ew ls_a1Ex -> : l_a1Ew (unwords_$sgo ls_a1Ex sc1_s1Gy)\r\n }\r\n\r\nunwords_go\r\nunwords_go =\r\n \\ b1_a1Fb ->\r\n case b1_a1Fb of _ {\r\n [] -> [];\r\n : ds_d1F5 ws_a1Ev ->\r\n case ds_d1F5 of _ {\r\n [] -> : lvl_r1EN (unwords_go ws_a1Ev);\r\n : l_a1Ew ls_a1Ex -> : l_a1Ew (unwords_$sgo ls_a1Ex ws_a1Ev)\r\n }\r\n }\r\nend Rec }\r\n\r\nunwords\r\nunwords = \\ b'_a1F9 -> unwords_go b'_a1F9\r\n}}}\r\n\r\nTo my untrained eye, that looks pretty reasonable.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9537concatMap is not a good producer for list fusion2019-07-07T18:40:07ZDavid FeuerconcatMap is not a good producer for list fusionJoachim Breitner raised this issue in an [email to haskell-cafe](http://www.haskell.org/pipermail/haskell-cafe/2011-December/097228.html) in 2011, but he never got a response. For some reason, list comprehensions desugar to `concatMap` f...Joachim Breitner raised this issue in an [email to haskell-cafe](http://www.haskell.org/pipermail/haskell-cafe/2011-December/097228.html) in 2011, but he never got a response. For some reason, list comprehensions desugar to `concatMap` forms written to fuse fully, but the actual `concatMap` function is not written so. Unless there is a good reason for this, we should make it fuse better.7.10.1Edward KmettEdward Kmetthttps://gitlab.haskell.org/ghc/ghc/-/issues/9536Implement foldr/cons/build2019-07-07T18:40:07ZDavid FeuerImplement foldr/cons/buildThere seem to be various issues with general `fold/cons` and even `cons/build` rules, but it seems pretty clear to me that the simple `fold/cons/build` rule is a good idea. It doesn't do much for nofib allocation, but it seems to improve...There seem to be various issues with general `fold/cons` and even `cons/build` rules, but it seems pretty clear to me that the simple `fold/cons/build` rule is a good idea. It doesn't do much for nofib allocation, but it seems to improve some other analyses and speed several benchmarks up, including speeding up some things that other fusion changes slowed down. I say "seems to" because I never trust my timings much at all.
```hs
{-# RULES
"foldr/cons/build" forall c n x (g::forall b. (a->b->b) -> b -> b) .
foldr c n (x:build g) = c x (g c n)
#-}
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.9 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett, hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Implement foldr/cons/build","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"7.8.4","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.9","keywords":["fusion"],"differentials":[],"test_case":"","architecture":"","cc":["ekmett","hvr"],"type":"Task","description":"There seem to be various issues with general `fold/cons` and even `cons/build` rules, but it seems pretty clear to me that the simple `fold/cons/build` rule is a good idea. It doesn't do much for nofib allocation, but it seems to improve some other analyses and speed several benchmarks up, including speeding up some things that other fusion changes slowed down. I say \"seems to\" because I never trust my timings much at all.\r\n\r\n{{{#!hs\r\n{-# RULES\r\n\"foldr/cons/build\" forall c n x (g::forall b. (a->b->b) -> b -> b) .\r\n foldr c n (x:build g) = c x (g c n)\r\n #-}\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9535Remove max_bytes_used from haddock tests2019-07-07T18:40:07ZJoachim Breitnermail@joachim-breitner.deRemove max_bytes_used from haddock testsSimon M says: “I think we should probably remove the max_bytes_used limits
for the Haddock tests.”
(I plan to “fix” this in the HIW contributors talk, so please do _not_ fix it just now :-))
<details><summary>Trac metadata</summary>
|...Simon M says: “I think we should probably remove the max_bytes_used limits
for the Haddock tests.”
(I plan to “fix” this in the HIW contributors talk, so please do _not_ fix it just now :-))
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.2 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Remove max_bytes_used from haddock tests","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"Simon M says: “I think we should probably remove the max_bytes_used limits \r\nfor the Haddock tests.”\r\n\r\n(I plan to “fix” this in the HIW contributors talk, so please do _not_ fix it just now :-))","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9532Expose new CLZ/CTZ primops via `Data.Bits` interface2019-07-07T18:40:08ZHerbert Valerio Riedelhvr@gnu.orgExpose new CLZ/CTZ primops via `Data.Bits` interfaceGHC now provides optimized CLZ/CTZ primops (see #9340), this ticket is about exposing those in a more convenient way.
This was proposed as
> http://www.haskell.org/pipermail/libraries/2014-August/023567.html
and passed (see also [prop...GHC now provides optimized CLZ/CTZ primops (see #9340), this ticket is about exposing those in a more convenient way.
This was proposed as
> http://www.haskell.org/pipermail/libraries/2014-August/023567.html
and passed (see also [proposal summary](http://www.haskell.org/pipermail/libraries/2014-August/023657.html))7.10.1Herbert Valerio Riedelhvr@gnu.orgHerbert Valerio Riedelhvr@gnu.orghttps://gitlab.haskell.org/ghc/ghc/-/issues/9531Implement Prelude.Word Proposal2019-07-07T18:40:08ZHerbert Valerio Riedelhvr@gnu.orgImplement Prelude.Word ProposalThis was proposed on the libraries list and succeeded by vote majority as well as by explicit
confirmation from the core libraries committee.
See [proposal summary](http://www.haskell.org/pipermail/libraries/2014-August/023658.html) for...This was proposed on the libraries list and succeeded by vote majority as well as by explicit
confirmation from the core libraries committee.
See [proposal summary](http://www.haskell.org/pipermail/libraries/2014-August/023658.html) for details.7.10.1Herbert Valerio Riedelhvr@gnu.orgHerbert Valerio Riedelhvr@gnu.orghttps://gitlab.haskell.org/ghc/ghc/-/issues/9529Clean up cseProgram2019-07-07T18:40:09ZDavid FeuerClean up cseProgramI think this should be a no-brainer:
Replace
```hs
cseProgram :: CoreProgram -> CoreProgram
cseProgram binds = cseBinds emptyCSEnv binds
cseBinds :: CSEnv -> [CoreBind] -> [CoreBind]
cseBinds _ [] = []
cseBinds env (b:bs) = (b':...I think this should be a no-brainer:
Replace
```hs
cseProgram :: CoreProgram -> CoreProgram
cseProgram binds = cseBinds emptyCSEnv binds
cseBinds :: CSEnv -> [CoreBind] -> [CoreBind]
cseBinds _ [] = []
cseBinds env (b:bs) = (b':bs')
where
(env1, b') = cseBind env b
bs' = cseBinds env1 bs
```
with
```hs
cseProgram :: CoreProgram -> CoreProgram
cseProgram = snd . mapAccumL cseBind emptyCSEnv
```
I'll attach a patch.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.9 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Clean up cseProgram","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"7.8.4","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.9","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I think this should be a no-brainer:\r\n\r\nReplace\r\n\r\n{{{#!hs\r\ncseProgram :: CoreProgram -> CoreProgram\r\ncseProgram binds = cseBinds emptyCSEnv binds\r\n\r\ncseBinds :: CSEnv -> [CoreBind] -> [CoreBind]\r\ncseBinds _ [] = []\r\ncseBinds env (b:bs) = (b':bs')\r\n where\r\n (env1, b') = cseBind env b\r\n bs' = cseBinds env1 bs\r\n}}}\r\n\r\nwith\r\n\r\n{{{#!hs\r\ncseProgram :: CoreProgram -> CoreProgram\r\ncseProgram = snd . mapAccumL cseBind emptyCSEnv\r\n}}}\r\n\r\nI'll attach a patch.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9527Add Generic instances for Language.Haskell.TH2019-07-07T18:40:09ZNiklas Hambüchenmail@nh2.meAdd Generic instances for Language.Haskell.THTemplate Haskell has a number of huge data types that would be much easier to work with if they had `Generic` instances.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ----------------...Template Haskell has a number of huge data types that would be much easier to work with if they had `Generic` instances.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------ |
| Version | 7.8.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | #9526 |
| Related | |
| Blocking | |
| CC | ekmett, hvr, mail@nh2.me |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[9526],"summary":"Add Generic instances for Language.Haskell.TH","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"7.10.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett","hvr","mail@nh2.me"],"type":"FeatureRequest","description":"Template Haskell has a number of huge data types that would be much easier to work with if they had `Generic` instances.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Richard Eisenbergrae@richarde.devRichard Eisenbergrae@richarde.devhttps://gitlab.haskell.org/ghc/ghc/-/issues/9510Prelude.!! is not a good consumer2019-07-07T18:40:13ZDavid FeuerPrelude.!! is not a good consumerI think we can probably do something like this, but I haven't checked the Core yet:
```hs
xs !! n
| n < 0 = error "Prelude.!!: Negative index"
| otherwise = foldr go (error "Prelude.!!: index too large or list empty") xs n
whe...I think we can probably do something like this, but I haven't checked the Core yet:
```hs
xs !! n
| n < 0 = error "Prelude.!!: Negative index"
| otherwise = foldr go (error "Prelude.!!: index too large or list empty") xs n
where
go x _ 0 = x
go _ f k = f (k - 1)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett, hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Prelude.!! is not a good consumer","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":["fusion"],"differentials":[],"test_case":"","architecture":"","cc":["ekmett","hvr"],"type":"Bug","description":"I think we can probably do something like this, but I haven't checked the Core yet:\r\n\r\n{{{#!hs\r\nxs !! n\r\n | n < 0 = error \"Prelude.!!: Negative index\"\r\n | otherwise = foldr go (error \"Prelude.!!: index too large or list empty\") xs n\r\n where\r\n go x _ 0 = x\r\n go _ f k = f (k - 1)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Edward KmettEdward Kmetthttps://gitlab.haskell.org/ghc/ghc/-/issues/9508Rename package key2019-07-07T18:40:14ZEdward Z. YangRename package keyWe were planning on renaming package key to something different. The two proposals on the table are "package instance" (which I don't like) and "library ID".
<details><summary>Trac metadata</summary>
| Trac field | Value ...We were planning on renaming package key to something different. The two proposals on the table are "package instance" (which I don't like) and "library ID".
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.9 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Rename package key","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"ezyang"},"version":"7.9","keywords":["backpack"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"We were planning on renaming package key to something different. The two proposals on the table are \"package instance\" (which I don't like) and \"library ID\".","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Edward Z. YangEdward Z. Yanghttps://gitlab.haskell.org/ghc/ghc/-/issues/9497Silent typed holes2019-07-07T18:40:16ZMerijn VerstraatenSilent typed holesI have a UI feature request for -fwarn-typed-holes, currently there's two options: 1) typed holes are on (default) and GHC prints errors for types holes or 2) typed holes are off and GHC will print "not in scope" error and prematurely en...I have a UI feature request for -fwarn-typed-holes, currently there's two options: 1) typed holes are on (default) and GHC prints errors for types holes or 2) typed holes are off and GHC will print "not in scope" error and prematurely end compilation.
When writing haskell, I frequently want to typecheck my code before it's completely implemented. Before I used undefined/error, which worked but I was always worried about accidentally forgetting an undefined somewhere. With typed holes this is no longer a problem, but unfortunately the warnings from typed holes are so verbose they drown out the other type errors. This makes typechecking during refactoring rather onerous.
I propose adding a -fsilent-typed-holes and/or -ftreat-type-holes-as-undefined which enable typed holes, but silence any compile time warnings. It'd be nice if this flag treated holes as if "-fdefer-type-errors" was on, but ONLY for typed holes.
This would let me compile the code and fix warnings, ignoring the holes while developing, while still assuring that, when I remove the flag and compile "for real" I get an error about typed holes.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Silent typed holes","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":["holes,","typed","warnings"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"I have a UI feature request for -fwarn-typed-holes, currently there's two options: 1) typed holes are on (default) and GHC prints errors for types holes or 2) typed holes are off and GHC will print \"not in scope\" error and prematurely end compilation.\r\n\r\nWhen writing haskell, I frequently want to typecheck my code before it's completely implemented. Before I used undefined/error, which worked but I was always worried about accidentally forgetting an undefined somewhere. With typed holes this is no longer a problem, but unfortunately the warnings from typed holes are so verbose they drown out the other type errors. This makes typechecking during refactoring rather onerous.\r\n\r\nI propose adding a -fsilent-typed-holes and/or -ftreat-type-holes-as-undefined which enable typed holes, but silence any compile time warnings. It'd be nice if this flag treated holes as if \"-fdefer-type-errors\" was on, but ONLY for typed holes.\r\n\r\nThis would let me compile the code and fix warnings, ignoring the holes while developing, while still assuring that, when I remove the flag and compile \"for real\" I get an error about typed holes.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Merijn VerstraatenMerijn Verstraatenhttps://gitlab.haskell.org/ghc/ghc/-/issues/9495Do What I Mean RULES for foldr2 look shady2019-07-07T18:40:17ZDavid FeuerDo What I Mean RULES for foldr2 look shadyThere's a comment in the source:
```
The foldr2/right rule isn't exactly right, because it changes
the strictness of foldr2 (and thereby zip)
E.g. main = print (null (zip nonobviousNil (build undefined)))
where nonobviousNi...There's a comment in the source:
```
The foldr2/right rule isn't exactly right, because it changes
the strictness of foldr2 (and thereby zip)
E.g. main = print (null (zip nonobviousNil (build undefined)))
where nonobviousNil = f 3
f n = if n == 0 then [] else f (n-1)
I'm going to leave it though.
```
This rule is intended to allow `foldr2` to fuse with *either* argument list. There are thus two problems, one already documented and the other not:
1. The rule can turn working code into non-working code, although this seems to be *relatively* unlikely. (The problem the above example is showing is that if the left list ends at the same time the right list bottoms out, the world goes boom. So `foldr2 f [1,2,3,4] (1:2:3:4:undefined)` appears to be a problem. You could argue this is not a big deal, I suppose.
1. The `foldr2/left` and `foldr2/right` rules are not confluent. They are both active in all phases, but if both list arguments are good producers, they will each want to rewrite the expression differently. So if you actually care about which one fuses, you need to explicitly block fusion with one argument using `NOINLINE`, which of course could easily muck up some other optimization.
My uninformed opinion: nix the `foldr2/right` rule, and change the documentation to indicate that `foldr2` fuses with its *left* argument.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett, hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Do What I Mean RULES for foldr2 look shady","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett","hvr"],"type":"Bug","description":"There's a comment in the source:\r\n\r\n{{{\r\nThe foldr2/right rule isn't exactly right, because it changes\r\nthe strictness of foldr2 (and thereby zip)\r\n\r\nE.g. main = print (null (zip nonobviousNil (build undefined)))\r\n where nonobviousNil = f 3\r\n f n = if n == 0 then [] else f (n-1)\r\n\r\nI'm going to leave it though.\r\n}}}\r\n\r\nThis rule is intended to allow `foldr2` to fuse with ''either'' argument list. There are thus two problems, one already documented and the other not:\r\n\r\n1. The rule can turn working code into non-working code, although this seems to be ''relatively'' unlikely. (The problem the above example is showing is that if the left list ends at the same time the right list bottoms out, the world goes boom. So `foldr2 f [1,2,3,4] (1:2:3:4:undefined)` appears to be a problem. You could argue this is not a big deal, I suppose.\r\n\r\n2. The `foldr2/left` and `foldr2/right` rules are not confluent. They are both active in all phases, but if both list arguments are good producers, they will each want to rewrite the expression differently. So if you actually care about which one fuses, you need to explicitly block fusion with one argument using `NOINLINE`, which of course could easily muck up some other optimization.\r\n\r\nMy uninformed opinion: nix the `foldr2/right` rule, and change the documentation to indicate that `foldr2` fuses with its ''left'' argument.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9480Segfault in GHC API code using Shelly2019-07-07T18:40:18ZagibianskySegfault in GHC API code using ShellyA segfault occurs when using the GHC API with Shelly. I do not know why.
Here is a code snippet that triggers it:
```hs
import GHC
import GHC.Paths ( libdir )
import DynFlags
main = runGhc (Just libdir) $ do
dflags <- getSessionDyn...A segfault occurs when using the GHC API with Shelly. I do not know why.
Here is a code snippet that triggers it:
```hs
import GHC
import GHC.Paths ( libdir )
import DynFlags
main = runGhc (Just libdir) $ do
dflags <- getSessionDynFlags
setSessionDynFlags $ dflags { hscTarget = HscInterpreted,
ghcLink = LinkInMemory }
imports <- mapM parseImportDecl ["import Shelly", "import Prelude"]
setContext $ map IIDecl imports
runStmt "shelly undefined" RunToCompletion
```
Note that on Mac OS X, this has no output whatsoever. The segfault occurs on Ubuntu 14.04, with `uname -a` outputting the following:
```
Linux yed 3.13.0-34-generic #60-Ubuntu SMP Wed Aug 13 15:45:27 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
```
I cannot find any way to get this to work and have no idea what's up with this or why shelly triggers it.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHC API |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Segfault in GHC API code using Shelly","status":"New","operating_system":"","component":"GHC API","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"A segfault occurs when using the GHC API with Shelly. I do not know why. \r\n\r\nHere is a code snippet that triggers it:\r\n\r\n{{{#!hs\r\nimport GHC\r\nimport GHC.Paths ( libdir )\r\nimport DynFlags\r\n \r\nmain = runGhc (Just libdir) $ do\r\n dflags <- getSessionDynFlags\r\n setSessionDynFlags $ dflags { hscTarget = HscInterpreted,\r\n ghcLink = LinkInMemory }\r\n imports <- mapM parseImportDecl [\"import Shelly\", \"import Prelude\"]\r\n setContext $ map IIDecl imports\r\n runStmt \"shelly undefined\" RunToCompletion\r\n}}}\r\n\r\nNote that on Mac OS X, this has no output whatsoever. The segfault occurs on Ubuntu 14.04, with `uname -a` outputting the following:\r\n\r\n{{{\r\nLinux yed 3.13.0-34-generic #60-Ubuntu SMP Wed Aug 13 15:45:27 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux\r\n}}}\r\n\r\nI cannot find any way to get this to work and have no idea what's up with this or why shelly triggers it.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9449GHC.Prim documentation says "Safe Inferred"2019-07-07T18:40:21ZRichard Eisenbergrae@richarde.devGHC.Prim documentation says "Safe Inferred"The Haddock docs for GHC.Prim (for example, [here](http://haddocks.fpcomplete.com/fp/7.7/20131212-1/ghc-prim/GHC-Prim.html)) says that it is Safe-Inferred. This is very bogus.
When testing, I was (happily) unable to import `GHC.Prim` in...The Haddock docs for GHC.Prim (for example, [here](http://haddocks.fpcomplete.com/fp/7.7/20131212-1/ghc-prim/GHC-Prim.html)) says that it is Safe-Inferred. This is very bogus.
When testing, I was (happily) unable to import `GHC.Prim` into a `Safe` module, so I think this is just a documentation bug.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 7.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC.Prim documentation says \"Safe Inferred\"","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The Haddock docs for GHC.Prim (for example, [http://haddocks.fpcomplete.com/fp/7.7/20131212-1/ghc-prim/GHC-Prim.html here]) says that it is Safe-Inferred. This is very bogus.\r\n\r\nWhen testing, I was (happily) unable to import `GHC.Prim` into a `Safe` module, so I think this is just a documentation bug.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1thoughtpolicethoughtpolicehttps://gitlab.haskell.org/ghc/ghc/-/issues/9440Buggy binder swap in occurrence analysis2019-07-07T18:40:23ZafarmerBuggy binder swap in occurrence analysisOccurrence analysis on case alternatives performs a "binder swap", whereby occurrences of the scrutinee in alternative RHSs are replaced by the case binder when the scrutinee is a variable or a casted variable.
```
case x of w
C vs ->...Occurrence analysis on case alternatives performs a "binder swap", whereby occurrences of the scrutinee in alternative RHSs are replaced by the case binder when the scrutinee is a variable or a casted variable.
```
case x of w
C vs -> rhs
===
case x of w
C vs -> let x = w in rhs
```
This should check two conditions, mentioned in Note \[Binder swap\].
(a) x is free in `C vs -> rhs`, otherwise one of two bad things happen:
1) it is pointless
> 2) new binding of x would capture one of the alternative binders (vs)
> (b) w is not in vs
Neither of these conditions is actually being checked.
Additionally, the binder swap happens in the presence of casts:
```
case x |> co of w
C vs -> rhs
===
case x |> co of w
C vs -> let x = w |> sym co in rhs
```
But the analysis is not returning usage info for free coercion variables in co.
Condition (a) bit us in HERMIT when running `occurAnalyseExpr` on the following expression resulting from unfolding nested calls to `fst`:
```
case x_X11b of wild_a3YB
(,) x_a3YD ds1_a3YE ->
case x_a3YD of wild_a3YB
(,) x_a3YD ds1_a3YE -> x_a3YD
```
The analysis would erroneously result in:
```
case x_X11b of wild_a3YB
(,) x_a3YD ds1_a3YE ->
case x_a3YD of wild_a3YB
(,) x_a3YD ds1_a3YE -> let x_a3YD = wild_a3YB in x_a3YD
```
which is clearly Not Good.
Patch forthcoming via Phabricator. Unfortunately, I don't have a good test case that doesn't involve HERMIT, but can confirm this patch fixes the problem above.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Buggy binder swap in occurrence analysis","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Occurrence analysis on case alternatives performs a \"binder swap\", whereby occurrences of the scrutinee in alternative RHSs are replaced by the case binder when the scrutinee is a variable or a casted variable.\r\n\r\n{{{\r\ncase x of w\r\n C vs -> rhs\r\n===\r\ncase x of w\r\n C vs -> let x = w in rhs\r\n}}}\r\n\r\nThis should check two conditions, mentioned in Note [Binder swap].\r\n\r\n (a) x is free in `C vs -> rhs`, otherwise one of two bad things happen:\r\n 1) it is pointless\r\n 2) new binding of x would capture one of the alternative binders (vs)\r\n (b) w is not in vs\r\n\r\nNeither of these conditions is actually being checked.\r\n\r\nAdditionally, the binder swap happens in the presence of casts:\r\n\r\n{{{\r\ncase x |> co of w\r\n C vs -> rhs\r\n===\r\ncase x |> co of w\r\n C vs -> let x = w |> sym co in rhs\r\n}}}\r\n\r\nBut the analysis is not returning usage info for free coercion variables in co.\r\n\r\nCondition (a) bit us in HERMIT when running `occurAnalyseExpr` on the following expression resulting from unfolding nested calls to `fst`:\r\n\r\n{{{\r\ncase x_X11b of wild_a3YB\r\n (,) x_a3YD ds1_a3YE ->\r\n case x_a3YD of wild_a3YB\r\n (,) x_a3YD ds1_a3YE -> x_a3YD\r\n}}}\r\n\r\nThe analysis would erroneously result in:\r\n\r\n{{{\r\ncase x_X11b of wild_a3YB\r\n (,) x_a3YD ds1_a3YE ->\r\n case x_a3YD of wild_a3YB\r\n (,) x_a3YD ds1_a3YE -> let x_a3YD = wild_a3YB in x_a3YD\r\n}}}\r\n\r\nwhich is clearly Not Good.\r\n\r\nPatch forthcoming via Phabricator. Unfortunately, I don't have a good test case that doesn't involve HERMIT, but can confirm this patch fixes the problem above.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9423shutdownCapability sometimes loops indefinitely on OSX after hs_exit()2019-07-07T18:40:28ZAndreasVoellmyshutdownCapability sometimes loops indefinitely on OSX after hs_exit()Issue #9284 relates to `forkProcess`, which previously invoked the same code that is invoked by `hs_exit` and uncovered this problem. The resolution of #9284 is to not invoke the equivalent of `hs_exit` (for reasons that you can see in #...Issue #9284 relates to `forkProcess`, which previously invoked the same code that is invoked by `hs_exit` and uncovered this problem. The resolution of #9284 is to not invoke the equivalent of `hs_exit` (for reasons that you can see in #9284). However, `hs_exit` can be called by programs that explicitly create and teardown a Haskell runtime, so the problem displayed by #9284 can still occur for those programs.
The problem has only been observed on OS X, though it probably could occur on Linux OSes as well.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"shutdownCapability sometimes loops indefinitely on OSX after hs_exit()","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Bug","description":"Issue #9284 relates to `forkProcess`, which previously invoked the same code that is invoked by `hs_exit` and uncovered this problem. The resolution of #9284 is to not invoke the equivalent of `hs_exit` (for reasons that you can see in #9284). However, `hs_exit` can be called by programs that explicitly create and teardown a Haskell runtime, so the problem displayed by #9284 can still occur for those programs.\r\n\r\nThe problem has only been observed on OS X, though it probably could occur on Linux OSes as well.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9400poor performance when compiling modules with many Text literals at -O12019-07-07T18:40:33Zrwbartonpoor performance when compiling modules with many Text literals at -O1(Spawned from #9370; see there for original discussion)
Unpack the xmlhtml package and edit `src/Text/XmlHtml/HTML/Meta.hs` and remove the `OPTIONS_GHC` line at the top of the file that disables optimizations and build with `cabal buidl...(Spawned from #9370; see there for original discussion)
Unpack the xmlhtml package and edit `src/Text/XmlHtml/HTML/Meta.hs` and remove the `OPTIONS_GHC` line at the top of the file that disables optimizations and build with `cabal buidl`. Then GHC takes \~1.5GB and over a minute to build this single module.
Preliminary investigation indicates that Text's fromString and its constituent parts is being inlined repeatedly:
```
Inlining done: Data.String.fromString
Inlining done: Data.Text.$fIsStringText
Inlining done: Data.Text.pack
Inlining done: Data.Text.Internal.Fusion.unstream
Inlining done: Data.Text.Internal.Fusion.Common.map
Inlining done: Data.Text.Internal.Fusion.Common.streamList
Inlining done: Data.Text.Internal.safe
Inlining done: Data.Bits.$fBitsInt_$c.&.
Inlining done: Data.Text.Internal.Fusion.Types.$WYield
[ repeats ~4000 times ]
```
resulting in a very large intermediate program:
```
[ 1 of 10] Compiling Text.XmlHtml.HTML.Meta ( src/Text/XmlHtml/HTML/Meta.hs, dist/build/Text/XmlHtml/HTML/Meta.o )
*** Parser:
*** Renamer/typechecker:
*** Desugar:
Result size of Desugar (after optimization)
= {terms: 26,806, types: 14,467, coercions: 0}
*** Simplifier:
Result size of Simplifier iteration=1
= {terms: 31,052, types: 20,719, coercions: 0}
Result size of Simplifier
= {terms: 31,052, types: 20,719, coercions: 0}
*** Specialise:
Result size of Specialise
= {terms: 32,254, types: 22,696, coercions: 448}
*** Float out(FOS {Lam = Just 0, Consts = True, PAPs = False}):
Result size of Float out(FOS {Lam = Just 0,
Consts = True,
PAPs = False})
= {terms: 63,022, types: 59,045, coercions: 448}
*** Float inwards:
Result size of Float inwards
= {terms: 63,022, types: 59,045, coercions: 448}
*** Simplifier:
Result size of Simplifier iteration=1
= {terms: 28,537, types: 18,902, coercions: 654}
Result size of Simplifier iteration=2
= {terms: 28,157, types: 18,257, coercions: 152}
Result size of Simplifier iteration=3
= {terms: 28,074, types: 18,128, coercions: 140}
Result size of Simplifier iteration=4
= {terms: 28,068, types: 18,096, coercions: 61}
Result size of Simplifier
= {terms: 28,068, types: 18,096, coercions: 61}
*** Simplifier:
Result size of Simplifier iteration=1
= {terms: 43,941, types: 38,325, coercions: 61}
Result size of Simplifier
= {terms: 43,941, types: 38,325, coercions: 61}
*** Simplifier:
Result size of Simplifier iteration=1
= {terms: 689,670, types: 461,960, coercions: 146,725}
...
```
\[Edited: old output was not actually for `-O1` as described, but rather for the sequence described in #9370 of building with `-O0` after building another module with `-O1`.\]7.10.1xnyhpsxnyhpshttps://gitlab.haskell.org/ghc/ghc/-/issues/9396Code cleanup: warning: use of GNU old-style field designator extension2019-07-07T18:40:35Zjrp2014Code cleanup: warning: use of GNU old-style field designator extensionThe attached patch updates replaces GNU old-style designator syntax with C98 syntax for initializing structs.
This gets rid of warnings such as
```
rts/Profiling.c:90:1:
warning: use of GNU old-style field designator extension [-W...The attached patch updates replaces GNU old-style designator syntax with C98 syntax for initializing structs.
This gets rid of warnings such as
```
rts/Profiling.c:90:1:
warning: use of GNU old-style field designator extension [-Wgnu-designator]
CC_DECLARE(CC_MAIN, "MAIN", "MAIN", "<built-in>", CC_NOT_CAF, );
^
includes/rts/prof/CCS.h:215:13:
note: expanded from macro 'CC_DECLARE'
= {{ ccID : 0, \
```
> \^
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Code cleanup: warning: use of GNU old-style field designator extension","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The attached patch updates replaces GNU old-style designator syntax with C98 syntax for initializing structs.\r\n This gets rid of warnings such as \r\n\r\n{{{\r\nrts/Profiling.c:90:1:\r\n warning: use of GNU old-style field designator extension [-Wgnu-designator]\r\nCC_DECLARE(CC_MAIN, \"MAIN\", \"MAIN\", \"<built-in>\", CC_NOT_CAF, );\r\n^\r\n\r\nincludes/rts/prof/CCS.h:215:13:\r\n note: expanded from macro 'CC_DECLARE'\r\n = {{ ccID : 0, \\\r\n \r\n}}}\r\n ^\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9393execvpe should handle ENOTDIR2019-07-07T18:40:35Ziquiwexecvpe should handle ENOTDIRIf PATH environment variable contains non directory component,
execvpe fails by ENOTDIR.
For example, if "/tmp/foo" is a regular file, the following program fails with PATH contains "/tmp/foo".
```
module Main where
import System.Envi...If PATH environment variable contains non directory component,
execvpe fails by ENOTDIR.
For example, if "/tmp/foo" is a regular file, the following program fails with PATH contains "/tmp/foo".
```
module Main where
import System.Environment
import System.Posix.Process
main :: IO ()
main = do
env <- getEnvironment
executeFile "echo" True [] (Just env)
return ()
```
```
$ PATH=/tmp/foo:$PATH runghc a.hs
a.hs: echo: executeFile: inappropriate type (Not a directory)
```
See for example, https://github.com/haskell/cabal/issues/1723
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/unix |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"execvpe should handle ENOTDIR","status":"New","operating_system":"","component":"libraries/unix","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"If PATH environment variable contains non directory component,\r\nexecvpe fails by ENOTDIR.\r\n\r\nFor example, if \"/tmp/foo\" is a regular file, the following program fails with PATH contains \"/tmp/foo\".\r\n{{{\r\nmodule Main where\r\n\r\nimport System.Environment\r\nimport System.Posix.Process\r\n\r\nmain :: IO ()\r\nmain = do\r\n env <- getEnvironment\r\n executeFile \"echo\" True [] (Just env)\r\n return ()\r\n}}}\r\n\r\n{{{\r\n$ PATH=/tmp/foo:$PATH runghc a.hs \r\na.hs: echo: executeFile: inappropriate type (Not a directory)\r\n}}}\r\n\r\nSee for example, https://github.com/haskell/cabal/issues/1723","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1