GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:26:19Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/12504Windows: Using hsc2hs in combination with inline-c generates the .c files wit...2019-07-07T18:26:19ZrcookWindows: Using hsc2hs in combination with inline-c generates the .c files with invalid pathsRepro steps:
- Install Stack on a *Windows* development machine.
- Create new simple project with `stack new inlinecbug simple`.
- Rename `src/Main.hs` to `src/Main.hsc` in the `inlinecbug` project directory.
- Build project with `stack...Repro steps:
- Install Stack on a *Windows* development machine.
- Create new simple project with `stack new inlinecbug simple`.
- Rename `src/Main.hs` to `src/Main.hsc` in the `inlinecbug` project directory.
- Build project with `stack build` and run with `stack exec inlinecbug` to verify that hsc2hs works correctly.
- Replace content of `src/Main.hsc` with following:
```hs
{-# LANGUAGE QuasiQuotes #-}
{-# LANGUAGE TemplateHaskell #-}
import qualified Language.C.Inline as C
C.include "<math.h>"
main :: IO ()
main = do
x <- [C.exp| double{ cos(1) } |]
print x
```
- In `inlinecbug.cabal` add `inline-c` to the `build-depends` section of `executable inlinecbug`.
- Add the line `c-sources: src/Main.c` to the `executable inlinecbug` section.
- Rebuild with `stack build`.
Build will fail with a linker error referring to a undefined reference to an `inline_c_main...` function. List the files in the root directory of the project and you'll see that inline-c has generated a file with the name `srcMain.c`: i.e. the backslashes in the Windows path have been removed.
Building under Linux generates the C output file with the correct, expected path of `src/Main.c` and the program will compile, link and run as expected.
See also: https://github.com/fpco/inline-c/issues/508.0.2https://gitlab.haskell.org/ghc/ghc/-/issues/12503Template Haskell regression: GHC erroneously thinks a type variable is also a...2019-07-07T18:26:20ZRyan ScottTemplate Haskell regression: GHC erroneously thinks a type variable is also a kindThe following program compiles without issue on GHC 7.6.3 through GHC 7.10.3, but fails to compile on GHC 8.0.1 and GHC HEAD. (I added a CPP guard simply because the `DataD` constructor changed between 7.10 and 8.0.)
```hs
{-# LANGUAGE ...The following program compiles without issue on GHC 7.6.3 through GHC 7.10.3, but fails to compile on GHC 8.0.1 and GHC HEAD. (I added a CPP guard simply because the `DataD` constructor changed between 7.10 and 8.0.)
```hs
{-# LANGUAGE CPP #-}
{-# LANGUAGE KindSignatures #-}
{-# LANGUAGE PolyKinds #-}
{-# LANGUAGE TemplateHaskell #-}
{-# OPTIONS_GHC -ddump-splices #-}
module Regression where
import Language.Haskell.TH
data T k
class C a
$(do TyConI (DataD [] tName [ KindedTV kName kKind]
#if __GLASGOW_HASKELL__ >= 800
_
#endif
_ _) <- reify ''T
d <- instanceD (cxt []) (conT ''C `appT` (conT tName `appT` sigT (varT kName) kKind)) []
return [d])
```
```
$ /opt/ghc/8.0.1/bin/ghc Regression.hs
[1 of 1] Compiling Regression ( Regression.hs, Regression.o )
Regression.hs:(13,3)-(19,15): Splicing declarations
do { TyConI (DataD []
tName_a2RT
[KindedTV kName_a2RU kKind_a2RV]
_
_
_) <- reify ''T;
d_a31Y <- instanceD
(cxt [])
(conT ''C
`appT` (conT tName_a2RT `appT` sigT (varT kName_a2RU) kKind_a2RV))
[];
return [d_a31Y] }
======>
instance C (T (k_avB :: k_avC))
Regression.hs:13:3: error:
Variable ‘k_avB’ used as both a kind and a type
Did you intend to use TypeInType?
```
Somewhat confusingly, you can use `instance C (T (k_avB :: k_avC))` on its own, and it will compile without issue. Also, quoting it doesn't seem to trip up this bug, as this also compiles without issue:
```hs
{-# LANGUAGE CPP #-}
{-# LANGUAGE KindSignatures #-}
{-# LANGUAGE PolyKinds #-}
{-# LANGUAGE TemplateHaskell #-}
{-# OPTIONS_GHC -ddump-splices #-}
module WorksSomehow where
import Language.Haskell.TH
data T k
class C a
$([d| instance C (T k) |])
```
The original program has several workarounds:
1. Turn off `PolyKinds` (OK, this isn't a very good workaround...)
1. Add an explicit kind signature to `T`, e.g., `data T (k :: k1)`
1. Change the type variable of `T` to some other letter, e.g., `data T p` or `data T k1`
Given that (3) is a successful workaround, I strongly suspect that GHC is confusing the type variable `k` (which gets `ddump-splice`d as `k_avB`) with the kind variable `k` (which gets `ddump-splice`d as `k_avC`) due to their common prefix `k`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Template Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | goldfire |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Template Haskell regression: GHC erroneously thinks a type variable is also a kind","status":"New","operating_system":"","component":"Template Haskell","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":["TypeInType"],"differentials":[],"test_case":"","architecture":"","cc":["goldfire"],"type":"Bug","description":"The following program compiles without issue on GHC 7.6.3 through GHC 7.10.3, but fails to compile on GHC 8.0.1 and GHC HEAD. (I added a CPP guard simply because the `DataD` constructor changed between 7.10 and 8.0.)\r\n\r\n{{{#!hs\r\n{-# LANGUAGE CPP #-}\r\n{-# LANGUAGE KindSignatures #-}\r\n{-# LANGUAGE PolyKinds #-}\r\n{-# LANGUAGE TemplateHaskell #-}\r\n{-# OPTIONS_GHC -ddump-splices #-}\r\nmodule Regression where\r\n\r\nimport Language.Haskell.TH\r\n\r\ndata T k\r\nclass C a\r\n\r\n$(do TyConI (DataD [] tName [ KindedTV kName kKind]\r\n#if __GLASGOW_HASKELL__ >= 800\r\n _\r\n#endif\r\n _ _) <- reify ''T\r\n d <- instanceD (cxt []) (conT ''C `appT` (conT tName `appT` sigT (varT kName) kKind)) []\r\n return [d])\r\n}}}\r\n\r\n{{{\r\n$ /opt/ghc/8.0.1/bin/ghc Regression.hs \r\n[1 of 1] Compiling Regression ( Regression.hs, Regression.o )\r\nRegression.hs:(13,3)-(19,15): Splicing declarations\r\n do { TyConI (DataD []\r\n tName_a2RT\r\n [KindedTV kName_a2RU kKind_a2RV]\r\n _\r\n _\r\n _) <- reify ''T;\r\n d_a31Y <- instanceD\r\n (cxt [])\r\n (conT ''C\r\n `appT` (conT tName_a2RT `appT` sigT (varT kName_a2RU) kKind_a2RV))\r\n [];\r\n return [d_a31Y] }\r\n ======>\r\n instance C (T (k_avB :: k_avC))\r\n\r\nRegression.hs:13:3: error:\r\n Variable ‘k_avB’ used as both a kind and a type\r\n Did you intend to use TypeInType?\r\n}}}\r\n\r\nSomewhat confusingly, you can use `instance C (T (k_avB :: k_avC))` on its own, and it will compile without issue. Also, quoting it doesn't seem to trip up this bug, as this also compiles without issue:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE CPP #-}\r\n{-# LANGUAGE KindSignatures #-}\r\n{-# LANGUAGE PolyKinds #-}\r\n{-# LANGUAGE TemplateHaskell #-}\r\n{-# OPTIONS_GHC -ddump-splices #-}\r\nmodule WorksSomehow where\r\n\r\nimport Language.Haskell.TH\r\n\r\ndata T k\r\nclass C a\r\n\r\n$([d| instance C (T k) |])\r\n}}}\r\n\r\nThe original program has several workarounds:\r\n\r\n1. Turn off `PolyKinds` (OK, this isn't a very good workaround...)\r\n2. Add an explicit kind signature to `T`, e.g., `data T (k :: k1)`\r\n3. Change the type variable of `T` to some other letter, e.g., `data T p` or `data T k1`\r\n\r\nGiven that (3) is a successful workaround, I strongly suspect that GHC is confusing the type variable `k` (which gets `ddump-splice`d as `k_avB`) with the kind variable `k` (which gets `ddump-splice`d as `k_avC`) due to their common prefix `k`.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1Richard Eisenbergrae@richarde.devRichard Eisenbergrae@richarde.devhttps://gitlab.haskell.org/ghc/ghc/-/issues/12502Reject wrong find utility2019-07-07T18:26:20ZTamar ChristinaReject wrong find utilityCurrently our configure scripts try to find the correct find tool on the `PATH`.
However because Windows also has a utility named `find`, depending on the user's configuration the Windows one may be on the path first.
The Configure scr...Currently our configure scripts try to find the correct find tool on the `PATH`.
However because Windows also has a utility named `find`, depending on the user's configuration the Windows one may be on the path first.
The Configure script currently rejects the tool and continues trying to find the correct `find` utility from `msys2`.
However the binary distribution script doesn't get to know which find utility to use. So if the wrong `find` is on the path then the windows binary downloads will fail with a weird error.
The find utility to use should probably be passed to the tarballs download script. We could just stuff it in an `Env variable` and use it in the script if available.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| 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":"Reject wrong find utility","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":["newcomer"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Currently our configure scripts try to find the correct find tool on the `PATH`. \r\n\r\nHowever because Windows also has a utility named `find`, depending on the user's configuration the Windows one may be on the path first.\r\n\r\nThe Configure script currently rejects the tool and continues trying to find the correct `find` utility from `msys2`. \r\n\r\nHowever the binary distribution script doesn't get to know which find utility to use. So if the wrong `find` is on the path then the windows binary downloads will fail with a weird error.\r\n\r\nThe find utility to use should probably be passed to the tarballs download script. We could just stuff it in an `Env variable` and use it in the script if available.","type_of_failure":"OtherFailure","blocking":[]} -->8.4.1https://gitlab.haskell.org/ghc/ghc/-/issues/12501Windows builds segfault (as in doesn't work at all).2019-07-07T18:26:20ZTamar ChristinaWindows builds segfault (as in doesn't work at all).Commit a9bc54766ddd1bdb011f1656ad58fb409055d08f is the last known good commit for the Windows build of GHC.
After this point multiple segfaults were introduced due to changes in the rts and GC.
One was introduced by the compacts region...Commit a9bc54766ddd1bdb011f1656ad58fb409055d08f is the last known good commit for the Windows build of GHC.
After this point multiple segfaults were introduced due to changes in the rts and GC.
One was introduced by the compacts regions patch cf989ffe490c146be4ed0fd7e0c00d3ff8fe1453 but fixed by f9a11a241b8056ac2b9c771172a48919fb3d0ed1
Unfortunately because many of the intermediate commits between cf989ffe490c146be4ed0fd7e0c00d3ff8fe1453 also break the build I can't run a proper bisect. And because of some very large commits in between it makes it really hard to cherry-pick individual commits or rebase certain ones out manually to try.
Effectively something was committed that makes GC go horribly wrong.
```
Tamar@Kino MINGW64 ~/ghc2
$ inplace/bin/ghc-stage2.exe --version
The Glorious Glasgow Haskell Compilation System, version 8.1.20160817
Segmentation fault
```
In GDB
```
Program received signal SIGSEGV, Segmentation fault.
0x0000000002aa35d9 in LOOKS_LIKE_CLOSURE_PTR (p=0x2cd1dd000000000) at includes/rts/storage/ClosureMacros.h:275
275 (UNTAG_CONST_CLOSURE((const StgClosure *)(p)))->header.info);
(gdb) bt
#0 0x0000000002aa35d9 in LOOKS_LIKE_CLOSURE_PTR (p=0x2cd1dd000000000) at includes/rts/storage/ClosureMacros.h:275
#1 0x0000000002aa3e3e in evacuate1 (p=0x31c1a04 <S4UR_srt+4>) at rts\sm\Evac.c:416
#2 0x0000000002a7a183 in scavenge_srt (srt=0x31c1a04 <S4UR_srt+4>, srt_bitmap=1) at rts\sm\Scav.c:351
#3 0x0000000002a7a253 in scavenge_fun_srt (info=0x278dfb0 <c1Fi_info+88>) at rts\sm\Scav.c:390
#4 0x0000000002a7c245 in scavenge_static () at rts\sm\Scav.c:1747
#5 0x0000000002a7c8f2 in scavenge_loop1 () at rts\sm\Scav.c:2081
#6 0x0000000002a722bb in scavenge_until_all_done () at rts\sm\GC.c:968
#7 0x0000000002a71008 in GarbageCollect (collect_gen=1, do_heap_census=rtsFalse, gc_type=2, cap=0x320f5c0 <MainCapability>) at rts\sm\GC.c:403
#8 0x0000000002a61856 in scheduleDoGC (pcap=0x3b4fbb8, task=0x6c6e0d0, force_major=rtsFalse) at rts\Schedule.c:1797
#9 0x0000000002a5fb68 in schedule (initialCapability=0x320f5c0 <MainCapability>, task=0x6c6e0d0) at rts\Schedule.c:552
#10 0x0000000002a62355 in scheduleWaitThread (tso=0x7205b98, ret=0x0, pcap=0x3b4fd40) at rts\Schedule.c:2494
#11 0x0000000002a4e24a in rts_evalLazyIO (cap=0x3b4fd40, p=0x2aabad0 <ZCMain_main_closure>, ret=0x0) at rts\RtsAPI.c:500
#12 0x0000000002a4d350 in hs_main (argc=1, argv=0x6c640b0, main_closure=0x2aabad0 <ZCMain_main_closure>, rts_config=...) at rts\RtsMain.c:64
#13 0x00000000004b4c75 in main ()
```
It seems that all `info` tables are messed up.
In `frame #4` the table contains very suspicious values:
```
(gdb) frame 4
#4 0x0000000002a7c245 in scavenge_static () at rts\sm\Scav.c:1747
1747 scavenge_fun_srt(info);
(gdb) p info
$3 = (const StgInfoTable *) 0x278dfb0 <c1Fi_info+88>
(gdb) pinfo info
$4 = {layout = {payload = {ptrs = 10697284, nptrs = 0}, bitmap = 10697284, large_bitmap_offset = 10697284, __pad_large_bitmap_offset = 10697284, selector_offset = 10697284}, type = 3, srt_bitmap = 1, code = 0x278dfb0 <c1Fi_info+88> ""}
```
Unfortunately my knowledge of GHC's `GC` is severely lacking at this moment so I have no idea how to debug this effectively and without knowing the commit that introduced it's rather slow going.
Any help or hints appreciated.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| 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":"Windows builds segfault (as in doesn't work at all).","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"Phyx-"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Commit a9bc54766ddd1bdb011f1656ad58fb409055d08f is the last known good commit for the Windows build of GHC.\r\n\r\nAfter this point multiple segfaults were introduced due to changes in the rts and GC. \r\n\r\nOne was introduced by the compacts regions patch cf989ffe490c146be4ed0fd7e0c00d3ff8fe1453 but fixed by f9a11a241b8056ac2b9c771172a48919fb3d0ed1\r\n\r\nUnfortunately because many of the intermediate commits between cf989ffe490c146be4ed0fd7e0c00d3ff8fe1453 also break the build I can't run a proper bisect. And because of some very large commits in between it makes it really hard to cherry-pick individual commits or rebase certain ones out manually to try.\r\n\r\nEffectively something was committed that makes GC go horribly wrong.\r\n\r\n{{{\r\nTamar@Kino MINGW64 ~/ghc2\r\n$ inplace/bin/ghc-stage2.exe --version\r\nThe Glorious Glasgow Haskell Compilation System, version 8.1.20160817\r\nSegmentation fault\r\n}}}\r\n\r\nIn GDB\r\n\r\n{{{\r\nProgram received signal SIGSEGV, Segmentation fault.\r\n0x0000000002aa35d9 in LOOKS_LIKE_CLOSURE_PTR (p=0x2cd1dd000000000) at includes/rts/storage/ClosureMacros.h:275\r\n275 (UNTAG_CONST_CLOSURE((const StgClosure *)(p)))->header.info);\r\n(gdb) bt\r\n#0 0x0000000002aa35d9 in LOOKS_LIKE_CLOSURE_PTR (p=0x2cd1dd000000000) at includes/rts/storage/ClosureMacros.h:275\r\n#1 0x0000000002aa3e3e in evacuate1 (p=0x31c1a04 <S4UR_srt+4>) at rts\\sm\\Evac.c:416\r\n#2 0x0000000002a7a183 in scavenge_srt (srt=0x31c1a04 <S4UR_srt+4>, srt_bitmap=1) at rts\\sm\\Scav.c:351\r\n#3 0x0000000002a7a253 in scavenge_fun_srt (info=0x278dfb0 <c1Fi_info+88>) at rts\\sm\\Scav.c:390\r\n#4 0x0000000002a7c245 in scavenge_static () at rts\\sm\\Scav.c:1747\r\n#5 0x0000000002a7c8f2 in scavenge_loop1 () at rts\\sm\\Scav.c:2081\r\n#6 0x0000000002a722bb in scavenge_until_all_done () at rts\\sm\\GC.c:968\r\n#7 0x0000000002a71008 in GarbageCollect (collect_gen=1, do_heap_census=rtsFalse, gc_type=2, cap=0x320f5c0 <MainCapability>) at rts\\sm\\GC.c:403\r\n#8 0x0000000002a61856 in scheduleDoGC (pcap=0x3b4fbb8, task=0x6c6e0d0, force_major=rtsFalse) at rts\\Schedule.c:1797\r\n#9 0x0000000002a5fb68 in schedule (initialCapability=0x320f5c0 <MainCapability>, task=0x6c6e0d0) at rts\\Schedule.c:552\r\n#10 0x0000000002a62355 in scheduleWaitThread (tso=0x7205b98, ret=0x0, pcap=0x3b4fd40) at rts\\Schedule.c:2494\r\n#11 0x0000000002a4e24a in rts_evalLazyIO (cap=0x3b4fd40, p=0x2aabad0 <ZCMain_main_closure>, ret=0x0) at rts\\RtsAPI.c:500\r\n#12 0x0000000002a4d350 in hs_main (argc=1, argv=0x6c640b0, main_closure=0x2aabad0 <ZCMain_main_closure>, rts_config=...) at rts\\RtsMain.c:64\r\n#13 0x00000000004b4c75 in main ()\r\n}}}\r\n\r\nIt seems that all `info` tables are messed up.\r\nIn `frame #4` the table contains very suspicious values:\r\n\r\n{{{\r\n(gdb) frame 4\r\n#4 0x0000000002a7c245 in scavenge_static () at rts\\sm\\Scav.c:1747\r\n1747 scavenge_fun_srt(info);\r\n(gdb) p info\r\n$3 = (const StgInfoTable *) 0x278dfb0 <c1Fi_info+88>\r\n(gdb) pinfo info\r\n$4 = {layout = {payload = {ptrs = 10697284, nptrs = 0}, bitmap = 10697284, large_bitmap_offset = 10697284, __pad_large_bitmap_offset = 10697284, selector_offset = 10697284}, type = 3, srt_bitmap = 1, code = 0x278dfb0 <c1Fi_info+88> \"\"}\r\n}}}\r\n\r\nUnfortunately my knowledge of GHC's `GC` is severely lacking at this moment so I have no idea how to debug this effectively and without knowing the commit that introduced it's rather slow going.\r\n\r\nAny help or hints appreciated.","type_of_failure":"OtherFailure","blocking":[]} -->Tamar ChristinaTamar Christinahttps://gitlab.haskell.org/ghc/ghc/-/issues/12500Open Type Family Kind Resolution2019-07-07T18:26:20ZAndrew MartinOpen Type Family Kind ResolutionThe following is a minimal example of this problem:
```hs
-- Section 1
data Animal = Dog | Cat | Mouse
data Planet = Earth | Jupiter | Mars | Saturn
type family ToRes (k :: Type) = (j :: Type)
type instance ToRes Planet = Animal
-- Sec...The following is a minimal example of this problem:
```hs
-- Section 1
data Animal = Dog | Cat | Mouse
data Planet = Earth | Jupiter | Mars | Saturn
type family ToRes (k :: Type) = (j :: Type)
type instance ToRes Planet = Animal
-- Section 2
type family Thing k (a :: k) = (b :: ToRes k)
type instance Thing Planet 'Earth = 'Dog
```
The last line fails with:
```
Expected kind 'ToRes Planet', but 'Dog has kind Animal
```
What's weird is that, if I take the part labeled Section 1 and move it into another module and then import that module into one that contains Section 2, it compiles fine. In this minimal case, that's not a huge problem, but for my real use case, splitting the type instances into two modules like this forces me to use an orphan.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| 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":"Open Type Family Kind Resolution","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following is a minimal example of this problem:\r\n\r\n{{{#!hs\r\n\r\n-- Section 1\r\ndata Animal = Dog | Cat | Mouse\r\ndata Planet = Earth | Jupiter | Mars | Saturn\r\ntype family ToRes (k :: Type) = (j :: Type)\r\ntype instance ToRes Planet = Animal\r\n\r\n-- Section 2\r\ntype family Thing k (a :: k) = (b :: ToRes k)\r\ntype instance Thing Planet 'Earth = 'Dog\r\n\r\n}}}\r\n\r\nThe last line fails with:\r\n\r\n{{{\r\nExpected kind 'ToRes Planet', but 'Dog has kind Animal\r\n}}}\r\n\r\nWhat's weird is that, if I take the part labeled Section 1 and move it into another module and then import that module into one that contains Section 2, it compiles fine. In this minimal case, that's not a huge problem, but for my real use case, splitting the type instances into two modules like this forces me to use an orphan.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12499Support multiple library import libs2019-07-07T18:26:21ZTamar ChristinaSupport multiple library import libsOur implementation of import libraries only support single library import libs.
These are by far the most common ones. However it is possible to make multi library import libraries.
E.g. one import library pointing to multiple dlls. `b...Our implementation of import libraries only support single library import libs.
These are by far the most common ones. However it is possible to make multi library import libraries.
E.g. one import library pointing to multiple dlls. `binutils` correct supports these and with #5987 GHC will be relying on them to work.
It makes sense that we are able to load them in GHCi as well. This will be required for a fully working dynamic GHC on Windows.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.0.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System (Linker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Support multiple library import libs","status":"New","operating_system":"","component":"Runtime System (Linker)","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Our implementation of import libraries only support single library import libs.\r\n\r\nThese are by far the most common ones. However it is possible to make multi library import libraries.\r\n\r\nE.g. one import library pointing to multiple dlls. `binutils` correct supports these and with #5987 GHC will be relying on them to work.\r\n\r\nIt makes sense that we are able to load them in GHCi as well. This will be required for a fully working dynamic GHC on Windows.","type_of_failure":"OtherFailure","blocking":[]} -->8.4.1Tamar ChristinaTamar Christinahttps://gitlab.haskell.org/ghc/ghc/-/issues/12497Make runtime linker be able to find POSIX functions under their deprecated name.2022-12-05T23:36:35ZTamar ChristinaMake runtime linker be able to find POSIX functions under their deprecated name.With GHC 8.0.1 the new runtime linker stopped re-exporting posix symbols under their deprecated names and instead follows the names on MSDN.
Unfortunately there seems to be far more libraries than expected using these deprecated names. ...With GHC 8.0.1 the new runtime linker stopped re-exporting posix symbols under their deprecated names and instead follows the names on MSDN.
Unfortunately there seems to be far more libraries than expected using these deprecated names. (Rather, far more libraries using posix functions and it happening to work on Windows).
These are all broken now, and while we're doing the right thing, for the sake of compatibility with mingw-w64's behavior and allowing all these packages to work then we should re-export these symbols.
e.g. rexport `strdup` as a forward from `_strdup`. We don't have to actually re-export them. just forward them in `RtsSymbol.c`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.0.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System (Linker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Make runtime linker be able to find POSIX functions under their deprecated name.","status":"New","operating_system":"","component":"Runtime System (Linker)","related":[],"milestone":"8.0.2","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":["newcomer"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"With GHC 8.0.1 the new runtime linker stopped re-exporting posix symbols under their deprecated names and instead follows the names on MSDN.\r\n\r\nUnfortunately there seems to be far more libraries than expected using these deprecated names. (Rather, far more libraries using posix functions and it happening to work on Windows). \r\n\r\nThese are all broken now, and while we're doing the right thing, for the sake of compatibility with mingw-w64's behavior and allowing all these packages to work then we should re-export these symbols.\r\n\r\ne.g. rexport `strdup` as a forward from `_strdup`. We don't have to actually re-export them. just forward them in `RtsSymbol.c`. ","type_of_failure":"OtherFailure","blocking":[]} -->8.0.2Tamar ChristinaTamar Christinahttps://gitlab.haskell.org/ghc/ghc/-/issues/12496GHCi reports unknown symbols in Win32 when linking C and C++ libs2022-02-05T20:14:43ZplGHCi reports unknown symbols in Win32 when linking C and C++ libsGHCi (win32, v8.0.1) gives strange unknown symbols when being run using a library that interfaces code written in C or C++. Compiled code runs fine.
As an example I use the eigen-2.1.6 package from hackage. However, it should be noted t...GHCi (win32, v8.0.1) gives strange unknown symbols when being run using a library that interfaces code written in C or C++. Compiled code runs fine.
As an example I use the eigen-2.1.6 package from hackage. However, it should be noted that I get a similar error message when trying to link a package that uses libgsl (gsl has been compiled with the mingw-gcc that ships with haskell-platform).
When I compile the little script from the eigen-manual on hackage
```hs
module Main where
import Data.Eigen.Matrix
import Data.Eigen.LA
main = do
let
a :: MatrixXd
a = fromList [[1,2,3], [4,5,6], [7,8,10]]
b = fromList [[3],[3],[4]]
x = solve ColPivHouseholderQR a b
putStrLn "Here is the matrix A:" >> print a
putStrLn "Here is the vector b:" >> print b
putStrLn "The solution is:" >> print x
```
I get (as expected):
```
Here is the matrix A:
Matrix 3x3
1.0 2.0 3.0
4.0 5.0 6.0
7.0 8.0 10.0
Here is the vector b:
Matrix 3x1
3.0
3.0
4.0
The solution is:
Matrix 3x1
-2.0
1.0000000000000016
0.9999999999999988
```
However, when I try to run it in GHCi I get
```
GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Main ( test.hs, interpreted )
Ok, modules loaded: Main.
*Main> main
ghc.exe: C:/Program Files (x86)/Haskell Platform/8.0.1/mingw/bin/../lib/gcc/i686-w64-mingw32/5.2.0/libstdc++.a: unknown
symbol `___emutls_get_address'
ghc.exe: Could not on-demand load symbol '___cxa_get_globals'
ghc.exe: C:/Program Files (x86)/Haskell Platform/8.0.1/mingw/bin/../lib/gcc/i686-w64-mingw32/5.2.0/libstdc++.a: unknown
symbol `___cxa_get_globals'
ghc.exe: Could not on-demand load symbol '___cxa_begin_catch'
ghc.exe: D:\Users\U439644\AppData\Roaming\cabal\i386-windows-ghc-8.0.1\eigen-2.1.6-6ZlfU8NIal9qgw3j5GclW\HSeigen-2.1.6-6
ZlfU8NIal9qgw3j5GclW.o: unknown symbol `___cxa_begin_catch'
ghc.exe: unable to load package `eigen-2.1.6'
```
I tried the same on OS X using GHCi v8.0.1. There everything works as expected.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| 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 reports unknown symbols in Win32 when linking C and C++ libs","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"GHCi (win32, v8.0.1) gives strange unknown symbols when being run using a library that interfaces code written in C or C++. Compiled code runs fine.\r\n\r\nAs an example I use the eigen-2.1.6 package from hackage. However, it should be noted that I get a similar error message when trying to link a package that uses libgsl (gsl has been compiled with the mingw-gcc that ships with haskell-platform). \r\n\r\nWhen I compile the little script from the eigen-manual on hackage\r\n{{{#!hs\r\nmodule Main where\r\n import Data.Eigen.Matrix\r\n import Data.Eigen.LA\r\n\r\n main = do\r\n let\r\n a :: MatrixXd\r\n a = fromList [[1,2,3], [4,5,6], [7,8,10]]\r\n b = fromList [[3],[3],[4]]\r\n x = solve ColPivHouseholderQR a b\r\n putStrLn \"Here is the matrix A:\" >> print a\r\n putStrLn \"Here is the vector b:\" >> print b\r\n putStrLn \"The solution is:\" >> print x\r\n}}}\r\nI get (as expected):\r\n{{{\r\nHere is the matrix A:\r\nMatrix 3x3\r\n1.0 2.0 3.0\r\n4.0 5.0 6.0\r\n7.0 8.0 10.0\r\n\r\nHere is the vector b:\r\nMatrix 3x1\r\n3.0\r\n3.0\r\n4.0\r\n\r\nThe solution is:\r\nMatrix 3x1\r\n-2.0\r\n1.0000000000000016\r\n0.9999999999999988\r\n}}}\r\n\r\nHowever, when I try to run it in GHCi I get\r\n{{{\r\nGHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help\r\n[1 of 1] Compiling Main ( test.hs, interpreted )\r\nOk, modules loaded: Main.\r\n*Main> main\r\nghc.exe: C:/Program Files (x86)/Haskell Platform/8.0.1/mingw/bin/../lib/gcc/i686-w64-mingw32/5.2.0/libstdc++.a: unknown\r\nsymbol `___emutls_get_address'\r\n\r\nghc.exe: Could not on-demand load symbol '___cxa_get_globals'\r\n\r\nghc.exe: C:/Program Files (x86)/Haskell Platform/8.0.1/mingw/bin/../lib/gcc/i686-w64-mingw32/5.2.0/libstdc++.a: unknown\r\nsymbol `___cxa_get_globals'\r\n\r\nghc.exe: Could not on-demand load symbol '___cxa_begin_catch'\r\n\r\nghc.exe: D:\\Users\\U439644\\AppData\\Roaming\\cabal\\i386-windows-ghc-8.0.1\\eigen-2.1.6-6ZlfU8NIal9qgw3j5GclW\\HSeigen-2.1.6-6\r\nZlfU8NIal9qgw3j5GclW.o: unknown symbol `___cxa_begin_catch'\r\n\r\nghc.exe: unable to load package `eigen-2.1.6'\r\n}}}\r\n\r\nI tried the same on OS X using GHCi v8.0.1. There everything works as expected. \r\n \r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12495GHC's configure script detects MADV_FREE when it shouldn't2019-07-07T18:26:22ZorionGHC's configure script detects MADV_FREE when it shouldn'tIn osDecommitMemory there is a [\#define](http://git.haskell.org/ghc.git/blob/4986837f8168cacf95c24fecc84d7b36c47f3c11:/rts/posix/OSMem.c#l507) for MADV_FREE. The presence of MADV_FREE is detected by the [configure](http://git.haskell.or...In osDecommitMemory there is a [\#define](http://git.haskell.org/ghc.git/blob/4986837f8168cacf95c24fecc84d7b36c47f3c11:/rts/posix/OSMem.c#l507) for MADV_FREE. The presence of MADV_FREE is detected by the [configure](http://git.haskell.org/ghc.git/blob/4986837f8168cacf95c24fecc84d7b36c47f3c11:/configure.ac#l1052) script, however merely testing for the presence of this symbol does not prove that MADV_FREE is supported by the kernel (which was [introduced in 4.5](https://kernelnewbies.org/Linux_4.5#head-42578a3e087d5bcc2940954a38ce794fe2cd642c)). On newer versions of GCC (e.g. 6.1.1 on Alpine Edge), [MADV_FREE is included in the compiler's header files](https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=981569c74cbb6bafa2ddcefa6dd9dbdc938ff1c8), thus leading to a false positive.
The impact of this bug is that when GHC is compiled with a more recent version of GCC, "unable to decommit memory: Invalid argument" errors will abound.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| 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":"GHC's configure script detects MADV_FREE when it shouldn't","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":["MADV_FREE"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In osDecommitMemory there is a [http://git.haskell.org/ghc.git/blob/4986837f8168cacf95c24fecc84d7b36c47f3c11:/rts/posix/OSMem.c#l507 #define] for MADV_FREE. The presence of MADV_FREE is detected by the [http://git.haskell.org/ghc.git/blob/4986837f8168cacf95c24fecc84d7b36c47f3c11:/configure.ac#l1052 configure] script, however merely testing for the presence of this symbol does not prove that MADV_FREE is supported by the kernel (which was [https://kernelnewbies.org/Linux_4.5#head-42578a3e087d5bcc2940954a38ce794fe2cd642c introduced in 4.5]). On newer versions of GCC (e.g. 6.1.1 on Alpine Edge), [https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=981569c74cbb6bafa2ddcefa6dd9dbdc938ff1c8 MADV_FREE is included in the compiler's header files], thus leading to a false positive.\r\n\r\nThe impact of this bug is that when GHC is compiled with a more recent version of GCC, \"unable to decommit memory: Invalid argument\" errors will abound.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12494Implementation of setenv in base incorrectly claims empty environment variabl...2019-07-07T18:26:22ZEdward Z. YangImplementation of setenv in base incorrectly claims empty environment variable not supported on WindowsRelevant code:
```
-- | @setEnv name value@ sets the specified environment variable to @value@.
--
-- On Windows setting an environment variable to the /empty string/ removes
-- that environment variable from the environment. For the s...Relevant code:
```
-- | @setEnv name value@ sets the specified environment variable to @value@.
--
-- On Windows setting an environment variable to the /empty string/ removes
-- that environment variable from the environment. For the sake of
-- compatibility we adopt that behavior. In particular
--
-- @
-- setEnv name \"\"
-- @
--
-- has the same effect as
--
-- @
-- `unsetEnv` name
-- @
```
This sounds nice and authoritative... and it's also not true.
https://msdn.microsoft.com/en-us/library/windows/desktop/ms686206(v=vs.85).aspx states that only if the pointer is NULL (as opposed to an empty string) is the environment variable deleted.
https://github.com/golang/go/issues/5610 corroborates
So `setEnv` has been given bogus semantics that don't make sense because empty environment variables ARE supported on Windows.
My suggestion is to just fix this so that setEnv takes empty environment variables. But this would be a BC breaking change.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Implementation of setenv in base incorrectly claims empty environment variable not supported on Windows","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Relevant code:\r\n\r\n{{{\r\n-- | @setEnv name value@ sets the specified environment variable to @value@.\r\n--\r\n-- On Windows setting an environment variable to the /empty string/ removes\r\n-- that environment variable from the environment. For the sake of\r\n-- compatibility we adopt that behavior. In particular\r\n--\r\n-- @\r\n-- setEnv name \\\"\\\"\r\n-- @\r\n--\r\n-- has the same effect as\r\n--\r\n-- @\r\n-- `unsetEnv` name\r\n-- @\r\n}}}\r\n\r\nThis sounds nice and authoritative... and it's also not true.\r\n\r\nhttps://msdn.microsoft.com/en-us/library/windows/desktop/ms686206(v=vs.85).aspx states that only if the pointer is NULL (as opposed to an empty string) is the environment variable deleted.\r\n\r\nhttps://github.com/golang/go/issues/5610 corroborates\r\n\r\nSo `setEnv` has been given bogus semantics that don't make sense because empty environment variables ARE supported on Windows.\r\n\r\nMy suggestion is to just fix this so that setEnv takes empty environment variables. But this would be a BC breaking change.","type_of_failure":"OtherFailure","blocking":[]} -->8.4.1https://gitlab.haskell.org/ghc/ghc/-/issues/12493Add gcoerceWith to Data.Type.Coercion2019-07-07T18:26:22ZRyan ScottAdd gcoerceWith to Data.Type.CoercionHaskell libraries mailing list discussion: https://mail.haskell.org/pipermail/libraries/2016-July/027207.html
> In Data.Type.Equality, we have both
>
> ```hs
> castWith :: (a :~: b) -> a -> b
> ```
>
> and
>
> ```hs
> gcastWith :: (a :~...Haskell libraries mailing list discussion: https://mail.haskell.org/pipermail/libraries/2016-July/027207.html
> In Data.Type.Equality, we have both
>
> ```hs
> castWith :: (a :~: b) -> a -> b
> ```
>
> and
>
> ```hs
> gcastWith :: (a :~: b) -> (a ~ b => r) -> r
> ```
>
> But in `Data.Type.Coercion` we only have
>
> ```hs
> coerceWith :: Coercion a b -> a -> b
> ```
>
> It seems to me that for the sake of consistency, we should add
>
> ```hs
> gcoerceWith :: Coercion a b -> (Coercible a b => r) -> r
> gcoerceWith Coercion a = a
> ```
>
> David Feuer
I've wanted this too. Patch incoming.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------------------------------- |
| Version | 8.0.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | core-libraries-committee@haskell.org, dfeuer |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add gcoerceWith to Data.Type.Coercion","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["core-libraries-committee@haskell.org","dfeuer"],"type":"FeatureRequest","description":"Haskell libraries mailing list discussion: https://mail.haskell.org/pipermail/libraries/2016-July/027207.html\r\n\r\n\r\n> In Data.Type.Equality, we have both\r\n> \r\n> {{{#!hs\r\n> castWith :: (a :~: b) -> a -> b\r\n> }}}\r\n> \r\n> and\r\n> \r\n> {{{#!hs\r\n> gcastWith :: (a :~: b) -> (a ~ b => r) -> r\r\n> }}}\r\n>\r\n> \r\n> But in `Data.Type.Coercion` we only have\r\n> \r\n> {{{#!hs\r\n> coerceWith :: Coercion a b -> a -> b\r\n> }}}\r\n> \r\n> It seems to me that for the sake of consistency, we should add\r\n> \r\n> {{{#!hs\r\n> gcoerceWith :: Coercion a b -> (Coercible a b => r) -> r\r\n> gcoerceWith Coercion a = a\r\n> }}}\r\n>\r\n> David Feuer\r\n\r\nI've wanted this too. Patch incoming.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/12492internal error: allocation of 1048608 bytes too large2020-11-11T12:32:32Zerikdinternal error: allocation of 1048608 bytes too largeI'm getting this error error when trying to use the `ghc-datasize` package from Hackage to calculate the in memory size of a data structure. The full error is:
```
load-test: internal error: allocation of 1048608 bytes too large (GHC
sh...I'm getting this error error when trying to use the `ghc-datasize` package from Hackage to calculate the in memory size of a data structure. The full error is:
```
load-test: internal error: allocation of 1048608 bytes too large (GHC
should have complained at compile-time)
(GHC version 8.0.1 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
However, this message is bogus because this is not a static data structure known at compile time, but data loaded from disk. Currently, my test program just loads this complex data structure (about 27 megabytes of CSV with embedded JSON on disk) into memory and then calls `recursiveSize` from `GHC.Datasize` on it. I get this same error message with both ghc7.10.3 and ghc-8.0.1.
If I remove the call to `recursiveSize` there is no error.
If I `Control.Deepseq.force` the data structures before calling `recursiveSize` there is no error.
So, who is to blame? `ghc-datasize` is just Haskell code that calls public APIs so I think the blame lies with GHC.
I'll work on getting a small re-producable test case.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1 |
| 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":"internal error: allocation of 1048608 bytes too large","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"8.0.2","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Bug","description":"I'm getting this error error when trying to use the `ghc-datasize` package from Hackage to calculate the in memory size of a data structure. The full error is:\r\n\r\n{{{\r\nload-test: internal error: allocation of 1048608 bytes too large (GHC\r\nshould have complained at compile-time)\r\n (GHC version 8.0.1 for x86_64_unknown_linux)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nHowever, this message is bogus because this is not a static data structure known at compile time, but data loaded from disk. Currently, my test program just loads this complex data structure (about 27 megabytes of CSV with embedded JSON on disk) into memory and then calls `recursiveSize` from `GHC.Datasize` on it. I get this same error message with both ghc7.10.3 and ghc-8.0.1.\r\n\r\nIf I remove the call to `recursiveSize` there is no error.\r\n\r\nIf I `Control.Deepseq.force` the data structures before calling `recursiveSize` there is no error.\r\n\r\nSo, who is to blame? `ghc-datasize` is just Haskell code that calls public APIs so I think the blame lies with GHC.\r\n\r\nI'll work on getting a small re-producable test case.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.2https://gitlab.haskell.org/ghc/ghc/-/issues/12491ghc-iserv pattern match failure with no command line arguments2019-07-07T18:26:22Zerikdghc-iserv pattern match failure with no command line argumentsWhile trying to debug the issue in #11981\##12491 I found that that `ghc-iserv` executable run without any arguments fails with a pattern match failure:
```
$ inplace/lib/bin/ghc-iserv
ghc-iserv: user error (Pattern match failure in do ...While trying to debug the issue in #11981\##12491 I found that that `ghc-iserv` executable run without any arguments fails with a pattern match failure:
```
$ inplace/lib/bin/ghc-iserv
ghc-iserv: user error (Pattern match failure in do expression at
iserv/src/Main.hs:28:3-18)
```
Would be far nicer if it printed out an error message saying what arguments it expected, or how to run it to avoid this pattern match failure.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc-iserv pattern match failure","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Bug","description":"While trying to debug the issue in https://ghc.haskell.org/trac/ghc/ticket/11981#comment:10 I found that that `ghc-iserv` executable run without any arguments fails with a pattern match failure:\r\n\r\n{{{\r\n$ inplace/lib/bin/ghc-iserv\r\nghc-iserv: user error (Pattern match failure in do expression at\r\n iserv/src/Main.hs:28:3-18)\r\n}}}\r\n\r\nWould be far nicer if it printed out an error message saying what arguments it expected, or how to run it to avoid this pattern match failure.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.2https://gitlab.haskell.org/ghc/ghc/-/issues/12490With RebindableSyntax, ApplicativeDo should eliminate return/pure2019-07-07T18:26:23ZAaronFrielWith RebindableSyntax, ApplicativeDo should eliminate return/pureIn a module with -XApplicativeDo, -XRebindableSyntax, and local definitions for everything in the Functor-Applicative-Monad hierarchy, do-notation always desugars to "join (... (return ...))" (or /s/return/pure/). This forces the result ...In a module with -XApplicativeDo, -XRebindableSyntax, and local definitions for everything in the Functor-Applicative-Monad hierarchy, do-notation always desugars to "join (... (return ...))" (or /s/return/pure/). This forces the result to have at least the constraints of join, which in my case is "IxMonad m".
```hs
{-# LANGUAGE RebindableSyntax, ApplicativeDo #-}
module My where
-- straightforward definitions of fmap, pure, (<*>), join, return, (>>=),
-- (>>) and fail in terms of IxFunctor, IxPointed, IxApplicative, IxMonad
fPure m = do
a <- m
b <- m
pure (a, b)
fReturn m = do
a <- m
b <- m
return (a, b)
```
According to -ddump-ds, these desugar to:
```hs
fPure :: IxMonad m => m k1 k1 a -> m k1 k1 (a, a)
fPure m = My.join ( My.(<*>) (My.fmap (\a b -> My.pure (a, b)) m) m )
fReturn :: IxMonad m => m k1 k1 a -> m k1 k1 (a, a)
fReturn m = My.join ( My.(<*>) (My.fmap (\a b -> My.return (a, b)) m) m )
```
But I would expect:
```hs
fPure m = My.(<*>) (My.fmap (\a b -> (a, b)) m) m
fReturn m = -- same
```
It appears that when "return" is not from base, ApplicativeDo only partially desugars to the specification, and the final "return" or "pure" remains in the output.8.0.2Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/12489undefined in view pattern inside pattern synonym causes GHC to panic2019-07-07T18:26:23Zpkmxundefined in view pattern inside pattern synonym causes GHC to panicThe following:
```hs
{-# LANGUAGE PatternSynonyms, ViewPatterns #-}
pattern P :: a -> b
pattern P a <- (undefined -> a)
```
causes GHC HEAD and 8.0.1 to panic:
```
ghc: panic! (the 'impossible' happened)
(GHC version 8.1.20160813 f...The following:
```hs
{-# LANGUAGE PatternSynonyms, ViewPatterns #-}
pattern P :: a -> b
pattern P a <- (undefined -> a)
```
causes GHC HEAD and 8.0.1 to panic:
```
ghc: panic! (the 'impossible' happened)
(GHC version 8.1.20160813 for x86_64-unknown-linux):
StgCmmEnv: variable not found
```
Removing the pattern signature or moving `undefined` behind another name work however:
```hs
{-# LANGUAGE PatternSynonyms, ViewPatterns #-}
bottom :: a
bottom = undefined
pattern P :: a -> b
pattern P a <- (bottom -> a) -- OK!
-- No type signature
pattern P' a <- (undefined -> a) -- OK!
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.1 |
| 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":"undefined in view pattern inside pattern synonym causes GHC to panic","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE PatternSynonyms, ViewPatterns #-}\r\n\r\npattern P :: a -> b\r\npattern P a <- (undefined -> a)\r\n}}}\r\n\r\ncauses GHC HEAD and 8.0.1 to panic:\r\n\r\n{{{\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.1.20160813 for x86_64-unknown-linux):\r\n\tStgCmmEnv: variable not found\r\n}}}\r\n\r\nRemoving the pattern signature or moving `undefined` behind another name work however:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE PatternSynonyms, ViewPatterns #-}\r\n\r\nbottom :: a\r\nbottom = undefined\r\n\r\npattern P :: a -> b\r\npattern P a <- (bottom -> a) -- OK!\r\n\r\n-- No type signature\r\npattern P' a <- (undefined -> a) -- OK!\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.0.2https://gitlab.haskell.org/ghc/ghc/-/issues/12487configure.ac uses wrong triple information.2019-07-07T18:26:23ZTamar Christinaconfigure.ac uses wrong triple information.GHC's `configure` script seems to normalize the values returned from `config.guess`.
So for Windows it turns `x86_64-pc-mingw64` into `x86_64-unknown-mingw32`.
These mangled names are stored in the values `$BuildPlatform`, `$HostPlatfo...GHC's `configure` script seems to normalize the values returned from `config.guess`.
So for Windows it turns `x86_64-pc-mingw64` into `x86_64-unknown-mingw32`.
These mangled names are stored in the values `$BuildPlatform`, `$HostPlatform` and `$TargetPlatform`.
However further down the file when the comparison is done between the stage0 compiler and the host the normalized versions are not used.
So when normalization actually changes the triple this check will fail.
Not sure why it's worked for all this time..
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| 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":"configure.ac uses wrong triple information.","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"GHC's `configure` script seems to normalize the values returned from `config.guess`.\r\n\r\nSo for Windows it turns `x86_64-pc-mingw64` into `x86_64-unknown-mingw32`.\r\n\r\nThese mangled names are stored in the values `$BuildPlatform`, `$HostPlatform` and `$TargetPlatform`. \r\n\r\nHowever further down the file when the comparison is done between the stage0 compiler and the host the normalized versions are not used.\r\n\r\nSo when normalization actually changes the triple this check will fail.\r\n\r\nNot sure why it's worked for all this time..","type_of_failure":"OtherFailure","blocking":[]} -->8.0.2Tamar ChristinaTamar Christinahttps://gitlab.haskell.org/ghc/ghc/-/issues/12485-package-db flags now need to be sorted by dependency order2019-07-07T18:26:24Zniteria-package-db flags now need to be sorted by dependency orderAfter 39b71e81ec1044518f065d0055676d713521e483 putting the -package-db flags in the wrong order will result in a compile error:
```
<command line>: cannot satisfy -package-id b-1-XXX:
b-1-XXX is unusable due to missing or recursive ...After 39b71e81ec1044518f065d0055676d713521e483 putting the -package-db flags in the wrong order will result in a compile error:
```
<command line>: cannot satisfy -package-id b-1-XXX:
b-1-XXX is unusable due to missing or recursive dependencies:
a-1-XXX
(use -v for more information)
```
See attached file for a repro.
It's reproduces in 8.0.1 and HEAD. Doesn't reproduce in GHC 7.10.3 or after reverting the above mentioned commit.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ezyang |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"-package-db flags now need to be sorted by dependency order","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ezyang"],"type":"Bug","description":"After 39b71e81ec1044518f065d0055676d713521e483 putting the -package-db flags in the wrong order will result in a compile error:\r\n{{{\r\n<command line>: cannot satisfy -package-id b-1-XXX:\r\n b-1-XXX is unusable due to missing or recursive dependencies:\r\n a-1-XXX\r\n (use -v for more information)\r\n}}}\r\n\r\nSee attached file for a repro.\r\n\r\nIt's reproduces in 8.0.1 and HEAD. Doesn't reproduce in GHC 7.10.3 or after reverting the above mentioned commit.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.3https://gitlab.haskell.org/ghc/ghc/-/issues/12484Missing pattern synonym signatures gives incorrect fix2019-07-07T18:26:24ZAlan ZimmermanMissing pattern synonym signatures gives incorrect fixThe following pattern definition
```hs
pattern RP pname help type' <- ParamDesc pname help type' Required
where RP pname help type' = ParamDesc pname help type' Required
```
Gives the warning
```
/....../PluginTypes.hs:248:1: wa...The following pattern definition
```hs
pattern RP pname help type' <- ParamDesc pname help type' Required
where RP pname help type' = ParamDesc pname help type' Required
```
Gives the warning
```
/....../PluginTypes.hs:248:1: warning: [-Wmissing-signatures]
Top-level binding with no type signature:
RP :: ParamName -> ParamHelp -> ParamType -> ParamDescription
```
The required signature is in fact
```hs
pattern RP :: ParamName -> ParamHelp -> ParamType -> ParamDescription
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | mpickering |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Missing pattern synonym signatures gives incorrect fix","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["mpickering"],"type":"Bug","description":"The following pattern definition\r\n\r\n{{{#!hs\r\npattern RP pname help type' <- ParamDesc pname help type' Required\r\n where RP pname help type' = ParamDesc pname help type' Required\r\n}}}\r\n\r\nGives the warning\r\n\r\n{{{\r\n /....../PluginTypes.hs:248:1: warning: [-Wmissing-signatures]\r\n Top-level binding with no type signature:\r\n RP :: ParamName -> ParamHelp -> ParamType -> ParamDescription\r\n}}}\r\n\r\nThe required signature is in fact\r\n\r\n{{{#!hs\r\npattern RP :: ParamName -> ParamHelp -> ParamType -> ParamDescription\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.2https://gitlab.haskell.org/ghc/ghc/-/issues/12482Infinite compilation time when using wrongly ordered constraints2021-03-31T13:29:06Zdanilo2Infinite compilation time when using wrongly ordered constraintsHello guys!
I've seen today a very strange bug in GHC 8. Namely I've got an instance:
```
instance {-# OVERLAPPABLE #-}
(PrimMonad m, g ~ HMGraph s rels, (g ^. t) ~ Hetero2 (MAutoVector s), s ~ PrimState m, HasProperty2' t g)
...Hello guys!
I've seen today a very strange bug in GHC 8. Namely I've got an instance:
```
instance {-# OVERLAPPABLE #-}
(PrimMonad m, g ~ HMGraph s rels, (g ^. t) ~ Hetero2 (MAutoVector s), s ~ PrimState m, HasProperty2' t g)
=> DynamicM t (HMGraph s rels) m a where
addM el = nested (prop2' @t . wrapped') $ (swap ∘ fmap Ptr) <∘> ixed Cont.addM (unsafeCoerce el)
```
and I'm using it indirectly in Main.hs. It compiles fast and works fine. The problem is that when I change the above constraint to:
```
(PrimMonad m, HasProperty2' t g, g ~ HMGraph s rels, (g ^. t) ~ Hetero2 (MAutoVector s), s ~ PrimState m)
```
Which is basically the same but with different order, the file with this constraint compiles fast and fine, but Main.hs compiles infinite amount of time (I've killed it after 10 minutes). The problem is reproducible, but it is hard right now to make minimal example out of it (we are going to a conference with a product release and we cannot track it right now).
I post it here because maybe the bug is known, if not, after the release I'll try to provide more info. If you've got any questions I'd love to assist.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Infinite compilation time when using wrongly ordered constraints","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Hello guys!\r\nI've seen today a very strange bug in GHC 8. Namely I've got an instance:\r\n\r\n{{{\r\n\r\ninstance {-# OVERLAPPABLE #-}\r\n (PrimMonad m, g ~ HMGraph s rels, (g ^. t) ~ Hetero2 (MAutoVector s), s ~ PrimState m, HasProperty2' t g)\r\n => DynamicM t (HMGraph s rels) m a where\r\n addM el = nested (prop2' @t . wrapped') $ (swap ∘ fmap Ptr) <∘> ixed Cont.addM (unsafeCoerce el)\r\n\r\n}}}\r\n\r\nand I'm using it indirectly in Main.hs. It compiles fast and works fine. The problem is that when I change the above constraint to:\r\n\r\n{{{\r\n(PrimMonad m, HasProperty2' t g, g ~ HMGraph s rels, (g ^. t) ~ Hetero2 (MAutoVector s), s ~ PrimState m)\r\n}}}\r\n\r\nWhich is basically the same but with different order, the file with this constraint compiles fast and fine, but Main.hs compiles infinite amount of time (I've killed it after 10 minutes). The problem is reproducible, but it is hard right now to make minimal example out of it (we are going to a conference with a product release and we cannot track it right now). \r\n\r\nI post it here because maybe the bug is known, if not, after the release I'll try to provide more info. If you've got any questions I'd love to assist.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12481Add MonadFail instance for Either String2019-07-07T18:26:25ZhesiodAdd MonadFail instance for Either StringThere seems to be the low hanging fruit of a MonadFail instance for Either String.
```hs
instance MonadFail (Either String) where
fail = Left
```
<details><summary>Trac metadata</summary>
| Trac field | Value ...There seems to be the low hanging fruit of a MonadFail instance for Either String.
```hs
instance MonadFail (Either String) where
fail = Left
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add MonadFail instance for Either String","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett"],"type":"FeatureRequest","description":"There seems to be the low hanging fruit of a MonadFail instance for Either String.\r\n\r\n{{{#!hs\r\ninstance MonadFail (Either String) where\r\n fail = Left\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->