GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:57:51Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/4931hsc2hs emits invalid OPTIONS_GHC pragmas2019-07-07T18:57:51Zawsonhsc2hs emits invalid OPTIONS_GHC pragmasIf I write
```
#define FOO "bar baz"
```
in my hsc code, hsc2hs emits
```
{-# OPTIONS_GHC -optc-DFOO="bar baz" #-}
```
which GHC refuses to compile.
For my local hsc2hs I didn't bother with `goodForOptD` AI and have removed `outOpti...If I write
```
#define FOO "bar baz"
```
in my hsc code, hsc2hs emits
```
{-# OPTIONS_GHC -optc-DFOO="bar baz" #-}
```
which GHC refuses to compile.
For my local hsc2hs I didn't bother with `goodForOptD` AI and have removed `outOption` for `"define"` key in `outSpecial` altogether.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | hsc2hs |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"hsc2hs emits invalid OPTIONS_GHC pragmas","status":"New","operating_system":"","component":"hsc2hs","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"If I write\r\n{{{\r\n#define FOO \"bar baz\"\r\n}}}\r\nin my hsc code, hsc2hs emits\r\n{{{\r\n{-# OPTIONS_GHC -optc-DFOO=\"bar baz\" #-}\r\n}}}\r\nwhich GHC refuses to compile.\r\n\r\nFor my local hsc2hs I didn't bother with {{{goodForOptD}}} AI and have removed {{{outOption}}} for {{{\"define\"}}} key in {{{outSpecial}}} altogether.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Thomas MiedemaThomas Miedemahttps://gitlab.haskell.org/ghc/ghc/-/issues/7810make show VALUE=VAR depends on ghc-stage12019-07-07T18:48:00Zkgardasmake show VALUE=VAR depends on ghc-stage1I'm trying to debug some issues in GHC build system and its pretty annoying when I change some variable value in mk/config.mk and when I try to verify this by
```
make show VALUE=<var name>
```
it starts a build of ghc-stage1 compiler....I'm trying to debug some issues in GHC build system and its pretty annoying when I change some variable value in mk/config.mk and when I try to verify this by
```
make show VALUE=<var name>
```
it starts a build of ghc-stage1 compiler. Is that really needed? IMHO this looks like a bug as after running configure all variables in makefiles should be constant...
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.7 |
| 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":"make show VALUE=VAR depends on ghc-stage1","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I'm trying to debug some issues in GHC build system and its pretty annoying when I change some variable value in mk/config.mk and when I try to verify this by\r\n{{{\r\nmake show VALUE=<var name>\r\n}}}\r\nit starts a build of ghc-stage1 compiler. Is that really needed? IMHO this looks like a bug as after running configure all variables in makefiles should be constant...","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Thomas MiedemaThomas Miedemahttps://gitlab.haskell.org/ghc/ghc/-/issues/7854Constrained method type accepted in Haskell 98 mode2019-07-07T18:47:48ZrefoldConstrained method type accepted in Haskell 98 modeIf I understand [this paragraph](http://www.haskell.org/ghc/docs/7.6.2/html/users_guide/type-class-extensions.html#class-method-types) of the GHC manual correctly, the following code should be rejected in Haskell 98 mode:
```
{-# LANGUA...If I understand [this paragraph](http://www.haskell.org/ghc/docs/7.6.2/html/users_guide/type-class-extensions.html#class-method-types) of the GHC manual correctly, the following code should be rejected in Haskell 98 mode:
```
{-# LANGUAGE Haskell98 #-}
module Main where
class Compare a where
comp :: Eq a => a -> a -> Bool
```
However, it compiles fine for me both with 7.4.2 and 7.6.1.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.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":"Constrained method type accepted in Haskell 98 mode","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"If I understand [http://www.haskell.org/ghc/docs/7.6.2/html/users_guide/type-class-extensions.html#class-method-types this paragraph] of the GHC manual correctly, the following code should be rejected in Haskell 98 mode:\r\n\r\n{{{\r\n{-# LANGUAGE Haskell98 #-}\r\n\r\nmodule Main where\r\n\r\nclass Compare a where\r\n comp :: Eq a => a -> a -> Bool\r\n}}}\r\n\r\nHowever, it compiles fine for me both with 7.4.2 and 7.6.1.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Thomas MiedemaThomas Miedemahttps://gitlab.haskell.org/ghc/ghc/-/issues/9087Executables in the Linux binaries are not stripped2019-07-07T18:41:59ZrefoldExecutables in the Linux binaries are not strippedThe executables inside the GHC binary tarball seem to come with debug information. Stripping it noticeably reduces the binary sizes:
```
$ file /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc
/path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc: ELF 32-bi...The executables inside the GHC binary tarball seem to come with debug information. Stripping it noticeably reduces the binary sizes:
```
$ file /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc
/path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=0x6012a4c86cd3f410ca0e59ab4ac872ce740d03c6, not stripped
$ du -sh /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc
1,4M /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc
$ strip -s /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc
$ du -sh /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc
1021K /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc
$ du -sh /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/haddock
3,2M /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/haddock
$ strip -s /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/haddock
$ du -sh /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/haddock
2,3M /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/haddock
```
Do we really need to include the debug info for exes?8.0.1Thomas MiedemaThomas Miedemahttps://gitlab.haskell.org/ghc/ghc/-/issues/9261-S prints incorrect number of bound tasks2019-07-07T18:41:09Zedsko@edsko.net-S prints incorrect number of bound tasksIn `rts/Stats.c` we have:
```
statsPrintf(" TASKS: %d (%d bound, %d peak workers (%d total), using -N%d)\n",
taskCount, taskCount - workerCount,
peakWorkerCount, workerCount,
...In `rts/Stats.c` we have:
```
statsPrintf(" TASKS: %d (%d bound, %d peak workers (%d total), using -N%d)\n",
taskCount, taskCount - workerCount,
peakWorkerCount, workerCount,
n_capabilities);
```
but I think `taskCount - workerCount` must be wrong, because `taskCount` is the _current_ number of tasks, while `workerAcount` is the _total_ number of workers (accumulating). I think it should be:
```
statsPrintf(" TASKS: %d (%d bound, %d peak workers (%d total), using -N%d)\n",
taskCount, taskCount - currentWorkerCount,
peakWorkerCount, workerCount,
n_capabilities);
```8.0.1Thomas MiedemaThomas Miedemahttps://gitlab.haskell.org/ghc/ghc/-/issues/9760ghc -c 7.8 drops last char of file name if -osuf contains a dot2019-07-07T18:39:10ZNiklas Hambüchenmail@nh2.meghc -c 7.8 drops last char of file name if -osuf contains a dotI discovered that if I compile with `ghc -c -osuf .something Myfile.hs` where `Myfile.hs` contains TH and thus has to dynamically link in, say, `Other.hs`, I get the error that
```
Myfile.hs:1:1:
cannot find normal object file 'Othe...I discovered that if I compile with `ghc -c -osuf .something Myfile.hs` where `Myfile.hs` contains TH and thus has to dynamically link in, say, `Other.hs`, I get the error that
```
Myfile.hs:1:1:
cannot find normal object file 'Othe.dyn_o`
while linking an interpreted expression
```
So `Other` was wrongly made into `Othe`, dropping the last character.
If I don't pass `-osuf .something`, or have it not have a dot, everything's fine.
The trouble is that `-osuf .something` worked fine in GHC \<= 7.6.
So I believe this is a regression, or at least a very bad error message.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | aehlig@google.com, nh2 |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc -c 7.8 drops last char of file name if -osuf contains a dot","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"7.8.4","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["aehlig@google.com","nh2"],"type":"Bug","description":"I discovered that if I compile with `ghc -c -osuf .something Myfile.hs` where `Myfile.hs` contains TH and thus has to dynamically link in, say, `Other.hs`, I get the error that\r\n\r\n\r\n{{{\r\nMyfile.hs:1:1:\r\n cannot find normal object file 'Othe.dyn_o`\r\n while linking an interpreted expression\r\n}}}\r\n\r\nSo `Other` was wrongly made into `Othe`, dropping the last character.\r\n\r\nIf I don't pass `-osuf .something`, or have it not have a dot, everything's fine.\r\n\r\nThe trouble is that `-osuf .something` worked fine in GHC <= 7.6.\r\n\r\nSo I believe this is a regression, or at least a very bad error message.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Thomas MiedemaThomas Miedemahttps://gitlab.haskell.org/ghc/ghc/-/issues/10219ghc -x hspp test.hspp: cannot compile this file to desired target2019-07-07T18:37:02ZThomas Miedemaghc -x hspp test.hspp: cannot compile this file to desired target<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.1 |
| Type | Bug |
| TypeOfFailure |...<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Driver |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc -x hspp test.hspp: cannot compile to this file to desired target","status":"New","operating_system":"","component":"Driver","related":[],"milestone":"7.12.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"thomie"},"version":"7.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Thomas MiedemaThomas Miedemahttps://gitlab.haskell.org/ghc/ghc/-/issues/10220Imports from `.hspp` and `.hscpp` files not loaded in --make mode2019-07-07T18:37:02ZThomas MiedemaImports from `.hspp` and `.hscpp` files not loaded in --make modeThis is a regression.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.1 |
| Type | Bug |
| T...This is a regression.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Driver |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Imports from `.hspp` and `.hscpp` files not loaded in --make mode","status":"New","operating_system":"","component":"Driver","related":[],"milestone":"7.12.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"thomie"},"version":"7.8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This is a regression.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Thomas MiedemaThomas Miedemahttps://gitlab.haskell.org/ghc/ghc/-/issues/10223Cleanup `mk/build.mk.sample`2019-07-07T18:37:01ZThomas MiedemaCleanup `mk/build.mk.sample`The goal is to make build.mk.sample easier to understand for GHC developers.
There are currently 13 BuildFlavours available to us. It should be clear what the differences between them are, and if those differences are put there on purpo...The goal is to make build.mk.sample easier to understand for GHC developers.
There are currently 13 BuildFlavours available to us. It should be clear what the differences between them are, and if those differences are put there on purpose or it they are bugs. There is a certain amount of cargo culting going on in build.mk.sample, with settings just left alone for years because nobody dares touching them (-H64m -fasm) (or nobody cares).
Quiz question: what is the difference between the quick and the devel2 build is.
We should try to keep the changes backward-compatible, because there are blog posts etc out there that refer to the existing BuildFlavours.8.0.1Thomas MiedemaThomas Miedemahttps://gitlab.haskell.org/ghc/ghc/-/issues/10636Clear up difference between `WayDyn` and `Opt_Static`2019-07-07T18:34:56ZThomas MiedemaClear up difference between `WayDyn` and `Opt_Static`There are currently 2 different ways to test for a static or dynamic build:
1. Test if `WayDyn` is in `ways`
1. Test if `Opt_Static` is set
Unless there's a use-case for setting `WayDyn`/`Opt_Static` inconsistently (if so, please add a...There are currently 2 different ways to test for a static or dynamic build:
1. Test if `WayDyn` is in `ways`
1. Test if `Opt_Static` is set
Unless there's a use-case for setting `WayDyn`/`Opt_Static` inconsistently (if so, please add a `Note` somewhere), it should be possible to replace all queries of `Opt_Static` with an equivalent query of `WayDyn`. That would have prevented bug #8294.
See the comments in [D1017](https://phabricator.haskell.org/D1017).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.1 |
| 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":"Clear up difference between `WayDyn` and `Opt_Static`","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"There are currently 2 different ways to test for a static or dynamic build:\r\n\r\n1. Test if `WayDyn` is in `ways`\r\n2. Test if `Opt_Static` is set\r\n\r\nUnless there's a use-case for setting `WayDyn`/`Opt_Static` inconsistently (if so, please add a `Note` somewhere), it should be possible to replace all queries of `Opt_Static` with an equivalent query of `WayDyn`. That would have prevented bug #8294.\r\n\r\nSee the comments in Phab:D1017.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Thomas MiedemaThomas Miedemahttps://gitlab.haskell.org/ghc/ghc/-/issues/10735Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/...2019-07-07T18:34:15ZThomas MiedemaSmooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty`GHC has an internal copy of `pretty` in `compiler/utils/Pretty.hs`.
Todo:
- refactor GHC's copy to make it as similar as possible to `pretty`, without making any real code changes.
- apply the bug fixes that `pretty` received to GHC's ...GHC has an internal copy of `pretty` in `compiler/utils/Pretty.hs`.
Todo:
- refactor GHC's copy to make it as similar as possible to `pretty`, without making any real code changes.
- apply the bug fixes that `pretty` received to GHC's copy, making sure not to pick up any possible new bugs in the process.
According to (1):
> "There is one situation where the laws for pretty are ambiguous and leave room for choice. GHC decided one way and pretty the other."
- Find which law that is, and document the differences.
This hopefully allows us to close the following tickets for free: #1062, #1176 and #7666, maybe more.
Ideally we could remove GHC's copy altogether, but we're not there yet. GHC's copy uses FastString, which is supposedly needed for performance, whereas pretty uses `String`.
(1) https://github.com/haskell/pretty/issues/1
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------- |
| Version | 7.0.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | #1062, #1176, #7666 |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty`","status":"New","operating_system":"","component":"Compiler","related":[1062,1176,7666],"milestone":"7.12.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"GHC has an internal copy of `pretty` in `compiler/utils/Pretty.hs`. \r\n\r\nTodo:\r\n * refactor GHC's copy to make it as similar as possible to `pretty`, without making any real code changes.\r\n * apply the bug fixes that `pretty` received to GHC's copy, making sure not to pick up any possible new bugs in the process.\r\n\r\nAccording to (1):\r\n \r\n \"There is one situation where the laws for pretty are ambiguous and leave room for choice. GHC decided one way and pretty the other.\"\r\n\r\n * Find which law that is, and document the differences.\r\n\r\nThis hopefully allows us to close the following tickets for free: #1062, #1176 and #7666, maybe more.\r\n\r\nIdeally we could remove GHC's copy altogether, but we're not there yet. GHC's copy uses FastString, which is supposedly needed for performance, whereas pretty uses `String`.\r\n\r\n(1) https://github.com/haskell/pretty/issues/1","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Thomas MiedemaThomas Miedemahttps://gitlab.haskell.org/ghc/ghc/-/issues/11130GHCi should not defer typed holes2019-07-07T18:31:49ZThomas MiedemaGHCi should not defer typed holesIn the function `tcUserStmt` in compiler/typecheck/TcRnDriver.hs, before going over the different ways ('plans') to lift an expression typed at the prompt into the GHCi monad, `Opt_DeferTypeErrors` is disabled. Here is the accompanying c...In the function `tcUserStmt` in compiler/typecheck/TcRnDriver.hs, before going over the different ways ('plans') to lift an expression typed at the prompt into the GHCi monad, `Opt_DeferTypeErrors` is disabled. Here is the accompanying comment:
```
-- Ensure that type errors don't get deferred when type checking the
-- naked expression. Deferring type errors here is unhelpful because the
-- expression gets evaluated right away anyway. It also would potentially
-- emit redundant type-error warnings, one from each plan.
; plan <- unsetGOptM Opt_DeferTypeErrors $
```
Since `Opt_DeferTypeErrors` implies `Opt_DeferTypedHoles`, `Opt_DeferTypedHoles` should be disabled here as well. This will improve the error message for T10248.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHCi should not defer typed holes","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"8.0.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In the function `tcUserStmt` in compiler/typecheck/TcRnDriver.hs, before going over the different ways ('plans') to lift an expression typed at the prompt into the GHCi monad, `Opt_DeferTypeErrors` is disabled. Here is the accompanying comment:\r\n{{{\r\n -- Ensure that type errors don't get deferred when type checking the\r\n -- naked expression. Deferring type errors here is unhelpful because the\r\n -- expression gets evaluated right away anyway. It also would potentially\r\n -- emit redundant type-error warnings, one from each plan.\r\n ; plan <- unsetGOptM Opt_DeferTypeErrors $\r\n}}}\r\n\r\nSince `Opt_DeferTypeErrors` implies `Opt_DeferTypedHoles`, `Opt_DeferTypedHoles` should be disabled here as well. This will improve the error message for T10248.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Thomas MiedemaThomas Miedemahttps://gitlab.haskell.org/ghc/ghc/-/issues/11413GHC 8.1.20160111 fails to bootstrap itself.2019-07-07T18:30:31ZkgardasGHC 8.1.20160111 fails to bootstrap itself.Hello,
bootstrapping GHC HEAD with HEAD is broken. The failure looks like:
```
libraries/binary/src/Data/Binary/Builder/Base.hs:67:0: error:
missing binary operator before token "("
libraries/binary/src/Data/Binary/Builder/Base.hs...Hello,
bootstrapping GHC HEAD with HEAD is broken. The failure looks like:
```
libraries/binary/src/Data/Binary/Builder/Base.hs:67:0: error:
missing binary operator before token "("
libraries/binary/src/Data/Binary/Builder/Base.hs:114:0: error:
missing binary operator before token "("
libraries/binary/src/Data/Binary/Builder/Base.hs:123:0: error:
missing binary operator before token "("
`gcc' failed in phase `C pre-processor'. (Exit code: 1)
gmake[1]: *** [utils/ghc-cabal/dist/build/tmp/ghc-cabal] Error 1
gmake: *** [all] Error 2
```
I'm setting highest prio on this (as I feel) so lower this if you like.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett |
| Operating system | Solaris |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC 8.1.20160111 fails to bootstrap itself.","status":"New","operating_system":"Solaris","component":"Core Libraries","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett"],"type":"Bug","description":"Hello,\r\nbootstrapping GHC HEAD with HEAD is broken. The failure looks like:\r\n{{{\r\nlibraries/binary/src/Data/Binary/Builder/Base.hs:67:0: error:\r\n missing binary operator before token \"(\"\r\n\r\nlibraries/binary/src/Data/Binary/Builder/Base.hs:114:0: error:\r\n missing binary operator before token \"(\"\r\n\r\nlibraries/binary/src/Data/Binary/Builder/Base.hs:123:0: error:\r\n missing binary operator before token \"(\"\r\n`gcc' failed in phase `C pre-processor'. (Exit code: 1)\r\ngmake[1]: *** [utils/ghc-cabal/dist/build/tmp/ghc-cabal] Error 1\r\ngmake: *** [all] Error 2\r\n}}}\r\nI'm setting highest prio on this (as I feel) so lower this if you like.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Thomas MiedemaThomas Miedemahttps://gitlab.haskell.org/ghc/ghc/-/issues/11489Segmentation fault when .prof file not writeable2019-07-07T18:30:12ZThomas MiedemaSegmentation fault when .prof file not writeableTo reproduce:
```
$ echo 'main = return ()' > Test.hs
$ touch Test.prof
$ chmod -w Test.prof
$ ghc -prof Test.hs
[1 of 1] Compiling Main ( Test.hs, Test.o )
Linking Test ...
$ ./Test +RTS -hr{} -hc
Can't open profiling r...To reproduce:
```
$ echo 'main = return ()' > Test.hs
$ touch Test.prof
$ chmod -w Test.prof
$ ghc -prof Test.hs
[1 of 1] Compiling Main ( Test.hs, Test.o )
Linking Test ...
$ ./Test +RTS -hr{} -hc
Can't open profiling report file Test.prof
Segmentation fault (core dumped)
```
The warning is ok (maybe it should be an error?), but it shouldn't segfault.
Running `./Test +RTS -hr` works fine.
http://downloads.haskell.org/\~ghc/master/users-guide/profiling.html\#rts-options-for-heap-profiling:
- `-hc`: Breaks down the graph by the cost-centre stack which produced the data.
- `-hr⟨cc⟩`: Restrict the profile to closures with retainer sets containing cost-centre stacks with one of the specified cost centres at the top.
Bug exists since dbef766ce79e37a74468a07a93b15ba1f06fe8f8 (2002):
```
- you can now restrict a heap profile to certain retainer sets,
but still display by cost centre (or type, or closure or
whatever).
```
Because it didn't update this code+comment introduced in db61851c5472bf565cd1da900b33d6e033fd743d (2001):
```
// The following line was added by Sung; retainer/LDV profiling may need
// two output files, i.e., <program>.prof/hp.
if (RtsFlags.ProfFlags.doHeapProfile == HEAP_BY_RETAINER)
RtsFlags.ProfFlags.doHeapProfile = 0;
```
Another relevant commit a4e17de6a38eb37cabff165e8f280a236ffa8af6:
```
Author: simonmar <unknown>
Date: Wed Nov 28 15:42:26 2001 +0000
[project @ 2001-11-28 15:42:26 by simonmar]
Don't need the .prof file when LDV-profiling.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Profiling |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Segmentation fault when .prof file not writeable","status":"New","operating_system":"","component":"Profiling","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"To reproduce:\r\n{{{\r\n$ echo 'main = return ()' > Test.hs\r\n\r\n$ touch Test.prof\r\n\r\n$ chmod -w Test.prof\r\n\r\n$ ghc -prof Test.hs\r\n[1 of 1] Compiling Main ( Test.hs, Test.o )\r\nLinking Test ...\r\n\r\n$ ./Test +RTS -hr{} -hc\r\nCan't open profiling report file Test.prof\r\nSegmentation fault (core dumped)\r\n}}}\r\n\r\nThe warning is ok (maybe it should be an error?), but it shouldn't segfault.\r\n\r\nRunning `./Test +RTS -hr` works fine.\r\n\r\nhttp://downloads.haskell.org/~ghc/master/users-guide/profiling.html#rts-options-for-heap-profiling:\r\n* `-hc`: Breaks down the graph by the cost-centre stack which produced the data.\r\n* `-hr⟨cc⟩`: Restrict the profile to closures with retainer sets containing cost-centre stacks with one of the specified cost centres at the top.\r\n\r\nBug exists since dbef766ce79e37a74468a07a93b15ba1f06fe8f8 (2002):\r\n{{{\r\n- you can now restrict a heap profile to certain retainer sets,\r\n but still display by cost centre (or type, or closure or\r\n whatever).\r\n}}}\r\n\r\nBecause it didn't update this code+comment introduced in db61851c5472bf565cd1da900b33d6e033fd743d (2001):\r\n{{{\r\n// The following line was added by Sung; retainer/LDV profiling may need\r\n// two output files, i.e., <program>.prof/hp.\r\nif (RtsFlags.ProfFlags.doHeapProfile == HEAP_BY_RETAINER)\r\n RtsFlags.ProfFlags.doHeapProfile = 0;\r\n}}}\r\n\r\nAnother relevant commit a4e17de6a38eb37cabff165e8f280a236ffa8af6:\r\n{{{\r\nAuthor: simonmar <unknown>\r\nDate: Wed Nov 28 15:42:26 2001 +0000\r\n\r\n [project @ 2001-11-28 15:42:26 by simonmar]\r\n Don't need the .prof file when LDV-profiling.\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Thomas MiedemaThomas Miedemahttps://gitlab.haskell.org/ghc/ghc/-/issues/11579Bug in parser for named Haddock chunks since GHC 8.0.1-rc12019-07-07T18:29:44ZSimon Hengelsol@typeful.netBug in parser for named Haddock chunks since GHC 8.0.1-rc1Steps to reproduce:
```hs
-- Foo.hs
module Foo where
-- $bar some
-- named chunk
```
```hs
-- Extract.hs
module Extract where
import Prelude hiding (mod)
import Data.Generics
import DynFlags
import FastString
import GHC
import GHC.Pa...Steps to reproduce:
```hs
-- Foo.hs
module Foo where
-- $bar some
-- named chunk
```
```hs
-- Extract.hs
module Extract where
import Prelude hiding (mod)
import Data.Generics
import DynFlags
import FastString
import GHC
import GHC.Paths
extractDocStrings :: IO [String]
extractDocStrings = do
extract . pm_parsed_source <$> do
runGhc (Just libdir) $ do
_ <- getSessionDynFlags >>= setSessionDynFlags . setHaddockMode
guessTarget "Foo.hs" Nothing >>= setTargets . return
[mod] <- depanal [] False
parseModule mod
where
setHaddockMode :: DynFlags -> DynFlags
setHaddockMode dynflags = (gopt_set dynflags Opt_Haddock)
extract :: ParsedSource -> [String]
extract m = [unpackFS s | HsDocString s <- everything (++) ([] `mkQ` return) m]
```
Expected result: `extractDocStrings` returns `" some\n named chunk"`
Actual result: it returns `" some"` instead8.0.1Thomas MiedemaThomas Miedema