GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2024-01-09T16:22:59Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/16331REGRESSION: --supported-languages lies about supported languages, again2024-01-09T16:22:59ZHerbert Valerio Riedelhvr@gnu.orgREGRESSION: --supported-languages lies about supported languages, againTo make it short, recent version of GHC broke the very thing we fixed in #11102 for GHC 8.0. This is utterly frustrating to me. ;-(
Basically, if GHC advertises an extension, it's supposed to work without jumping through hoops if you en...To make it short, recent version of GHC broke the very thing we fixed in #11102 for GHC 8.0. This is utterly frustrating to me. ;-(
Basically, if GHC advertises an extension, it's supposed to work without jumping through hoops if you enable it via `{-# LANGUAGE ... #-}` or `-X`-flags. Otherwise this breaks the whole idea of `other-extensions` and related cabal spec features which use `--supported-languages` to infer whether e.g. GHC when invoked with `-XTemplateHaskell` will succeed.
However, consider the `Main.hs` below
```hs
{-# LANGUAGE TemplateHaskell #-}
main = $undefined
```
Unfortuantely now GHC lies unconditionally about supporting TH, thereby undermining the infrastructure we setup in and for #11102:
```
$ ghc --supported-languages | grep ^TemplateHaskell$
TemplateHaskell
$ ghc --make Foo.hs
[1 of 1] Compiling Main ( Foo.hs, Foo.o )
ghc-stage2: this operation requires -fexternal-interpreter
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"REGRESSION: --supported-languages lies about supported languages, again","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"To make it short, recent version of GHC broke the very thing we fixed in #11102 for GHC 8.0. This is utterly frustrating to me. ;-(\r\n\r\n\r\nBasically, if GHC advertises an extension, it's supposed to work without jumping through hoops if you enable it via `{-# LANGUAGE ... #-}` or `-X`-flags. Otherwise this breaks the whole idea of `other-extensions` and related cabal spec features which use `--supported-languages` to infer whether e.g. GHC when invoked with `-XTemplateHaskell` will succeed.\r\n\r\nHowever, consider the `Main.hs` below\r\n\r\n{{{#!hs\r\n{-# LANGUAGE TemplateHaskell #-}\r\n\r\nmain = $undefined\r\n}}}\r\n\r\nUnfortuantely now GHC lies unconditionally about supporting TH, thereby undermining the infrastructure we setup in and for #11102:\r\n\r\n{{{\r\n$ ghc --supported-languages | grep ^TemplateHaskell$\r\nTemplateHaskell\r\n\r\n$ ghc --make Foo.hs \r\n[1 of 1] Compiling Main ( Foo.hs, Foo.o )\r\nghc-stage2: this operation requires -fexternal-interpreter\r\n}}}\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Alp MestanogullariAlp Mestanogullarihttps://gitlab.haskell.org/ghc/ghc/-/issues/16026No way to run a subset of the testsuite2019-07-07T18:01:58ZBen GamariNo way to run a subset of the testsuiteCurrently Hadrian lacks an analogue of the `TEST=...` variables in the `make` build system's `test` target. In other words, it's not possible to run a subset of the testsuite.
<details><summary>Trac metadata</summary>
| Trac field ...Currently Hadrian lacks an analogue of the `TEST=...` variables in the `make` build system's `test` target. In other words, it's not possible to run a subset of the testsuite.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 8.6.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Build System (Hadrian) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"No way to run a subset of the testsuite","status":"New","operating_system":"","component":"Build System (Hadrian)","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Currently Hadrian lacks an analogue of the `TEST=...` variables in the `make` build system's `test` target. In other words, it's not possible to run a subset of the testsuite.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Alp MestanogullariAlp Mestanogullarihttps://gitlab.haskell.org/ghc/ghc/-/issues/15938Hadrian's recompilation check is extremely slow2019-07-07T18:02:22ZBen GamariHadrian's recompilation check is extremely slowI just Ctrl-C'd hadrian while it was building `libraries/base`, having noticed that I forgot to start it with `-j`. I then immediately restarted it and noticed that Hadrian needed to think for 45 seconds before it started even a single b...I just Ctrl-C'd hadrian while it was building `libraries/base`, having noticed that I forgot to start it with `-j`. I then immediately restarted it and noticed that Hadrian needed to think for 45 seconds before it started even a single build. This is orders of magnitude worse than `make` so something must be wrong.
I'm setting this at high priority since 45 seconds is longer than many complete `make` rebuilds.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 8.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Build System (Hadrian) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Hadrian's recompilation check is extremely slow","status":"New","operating_system":"","component":"Build System (Hadrian)","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I just Ctrl-C'd hadrian while it was building `libraries/base`, having noticed that I forgot to start it with `-j`. I then immediately restarted it and noticed that Hadrian needed to think for 45 seconds before it started even a single build. This is orders of magnitude worse than `make` so something must be wrong.\r\n\r\nI'm setting this at high priority since 45 seconds is longer than many complete `make` rebuilds.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Alp MestanogullariAlp Mestanogullarihttps://gitlab.haskell.org/ghc/ghc/-/issues/14506Configure Harbormaster to trigger CircleCI builds2019-07-07T18:16:45ZBen GamariConfigure Harbormaster to trigger CircleCI builds<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 8.2.1 |
| Type | Bug ...<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 8.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Continuous Integration |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Configure Harbormaster to trigger CircleCI commits","status":"New","operating_system":"","component":"Continuous Integration","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"bgamari"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Alp MestanogullariAlp Mestanogullarihttps://gitlab.haskell.org/ghc/ghc/-/issues/15949Hadrian needs more convenient build target names2019-07-07T18:02:19ZBen GamariHadrian needs more convenient build target namesWith the `make` build system one can easily build a particular library or executable by `cd`ing into the relevant directory and typing `make`. With `hadrian` there appears to be no convenient way to replicate this. Instead, you need to k...With the `make` build system one can easily build a particular library or executable by `cd`ing into the relevant directory and typing `make`. With `hadrian` there appears to be no convenient way to replicate this. Instead, you need to know the name of the final target which the build will produce which may contain version numbers, platform triples, and all sorts of other ugliness.
I suggest we introduce a set of convenience targets to make this easier. For instance one could run:
```
$ hadrian stage1:lib:ghc
```
to build the stage1 `ghc` library or
```
$ hadrian stage2:exe:hp2ps
```
to build `hp2ps`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 8.6.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | alpmestan, snowleopard |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Hadrian needs more convenient build target names","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["alpmestan","snowleopard"],"type":"FeatureRequest","description":"With the `make` build system one can easily build a particular library or executable by `cd`ing into the relevant directory and typing `make`. With `hadrian` there appears to be no convenient way to replicate this. Instead, you need to know the name of the final target which the build will produce which may contain version numbers, platform triples, and all sorts of other ugliness.\r\n\r\nI suggest we introduce a set of convenience targets to make this easier. For instance one could run:\r\n{{{\r\n$ hadrian stage1:lib:ghc\r\n}}}\r\nto build the stage1 `ghc` library or\r\n{{{\r\n$ hadrian stage2:exe:hp2ps\r\n}}}\r\nto build `hp2ps`.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Alp MestanogullariAlp Mestanogullarihttps://gitlab.haskell.org/ghc/ghc/-/issues/15671Link errors due to forcibly exporting findPtr2019-07-07T18:03:30ZTamar ChristinaLink errors due to forcibly exporting findPtrThe change in https://phabricator.haskell.org/rGHC900c47f88784b91517c00be3e1087322e62f698e is causing link errors due to the combination of `-Wl,-u` and `-Wl,--export-all-symbols`
```
Wrong exit code for T10955dyn()(expected 0 , actual ...The change in https://phabricator.haskell.org/rGHC900c47f88784b91517c00be3e1087322e62f698e is causing link errors due to the combination of `-Wl,-u` and `-Wl,--export-all-symbols`
```
Wrong exit code for T10955dyn()(expected 0 , actual 2 )
Stderr ( T10955dyn ):
E:/ghc-dev/msys64/home/Tamar/ghc/rts/dist/build/libHSrts_thr.a(Printer.thr_o): In function `findPtr':
E:\ghc-dev\msys64\home\Tamar\ghc/rts/Printer.c:880: multiple definition of `findPtr'
./bin_dyn/libA.dll.a(d020776.o):(.text+0x0): first defined here
```
I believe the correct solution is to just use a cabal flag to emulate the setup we had with make, instead of forcing this symbol always.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------------------------------- |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | [D5138](https://phabricator.haskell.org/D5138) |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Link errors due to forcibly exporting findPtr","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[5138],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The change in https://phabricator.haskell.org/rGHC900c47f88784b91517c00be3e1087322e62f698e is causing link errors due to the combination of `-Wl,-u` and `-Wl,--export-all-symbols`\r\n\r\n{{{\r\nWrong exit code for T10955dyn()(expected 0 , actual 2 )\r\nStderr ( T10955dyn ):\r\nE:/ghc-dev/msys64/home/Tamar/ghc/rts/dist/build/libHSrts_thr.a(Printer.thr_o): In function `findPtr':\r\nE:\\ghc-dev\\msys64\\home\\Tamar\\ghc/rts/Printer.c:880: multiple definition of `findPtr'\r\n./bin_dyn/libA.dll.a(d020776.o):(.text+0x0): first defined here\r\n}}}\r\n\r\nI believe the correct solution is to just use a cabal flag to emulate the setup we had with make, instead of forcing this symbol always.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Alp MestanogullariAlp Mestanogullarihttps://gitlab.haskell.org/ghc/ghc/-/issues/17140Inifinite inlining loop2019-09-13T09:45:01ZSimon Peyton JonesInifinite inlining loopGanesh Sittampalam [reports](https://mail.haskell.org/pipermail/glasgow-haskell-users/2019-August/026866.html):
The code below (also attached - unzip and run go.sh) triggers the GHC panic "Simplifier ticks exhausted", and I'm unsure whe...Ganesh Sittampalam [reports](https://mail.haskell.org/pipermail/glasgow-haskell-users/2019-August/026866.html):
The code below (also attached - unzip and run go.sh) triggers the GHC panic "Simplifier ticks exhausted", and I'm unsure whether I should view it as an instance of the [known infelicity in the inliner](https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/bugs.html#bugs-ghc)
My code does have a recursive datatype, but the recursion isn't contravariant, which is the case described in ["Secrets of the GHC inliner", Section 4](https://www.microsoft.com/en-us/research/wp-content/uploads/2002/07/inline.pdf).
It's cut down from some real code where I have a mutually recursive datatype that I want to define across two modules for code structuring reasons, meaning I need a .hs-boot file. I haven't been able to reproduce it without the .hs-boot file - if I put everything in one module it stops happening.
I've tried with a range of GHC versions from 8.2.x to an early version of 8.8. It happens with -O1 and not -O0, but I haven't managed to find a specific optimisation that triggers it.
Is this just an instance of the known problem in a different guise, or is it something different and worth a bug report?
Cheers,
Ganesh
```
T2.hs-boot
-----------
module T2 where
data T2
mapP_T2 :: (Int -> Int) -> T2 -> T2
T1.hs
-----
module T1 where
import {-# SOURCE #-} T2
data T1 = T1 T2
mapP_T1 :: (Int -> Int) -> T1 -> T1
mapP_T1 _ (T1 xs) = T1 (mapP_T2 id xs)
T2.hs
-----
module T2 where
import T1
data T2 = T2 T1
mapP_T2 :: (Int -> Int) -> T2 -> T2
mapP_T2 f (T2 t) = T2 (mapP_T1 f t)
go :: T1 -> T1
go = mapP_T1 id
```
Here is the GHC output
```
$ ghc --make T2.hs -O1 -fsimpl-tick-factor=1000 -ddump-simpl-stats) [...]
ghc.exe: panic! (the 'impossible' happened)
(GHC version 8.2.2 for x86_64-unknown-mingw32):
Simplifier ticks exhausted
When trying UnfoldingDone mapP_T2
To increase the limit, use -fsimpl-tick-factor=N (default 100)
If you need to do this, let GHC HQ know, and what factor you needed
Total ticks: 61203
24481 PreInlineUnconditionally
6121 ds_i17h
6120 f_a16p
6120 ds_d17d
6120 ds1_i17i
12241 UnfoldingDone
6121 mapP_T1
6120 mapP_T2
24481 BetaReduction
6121 ds_i17h
6120 f_a16p
6120 ds_d17d
6120 ds1_i17i
```8.8.1Alp MestanogullariAlp Mestanogullari