GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2022-10-12T11:09:16Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/7388CAPI doesn't work with ghci2022-10-12T11:09:16ZIan Lynagh <igloo@earth.li>CAPI doesn't work with ghci```
$ ghc -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history T4012 --interactive -ignore-dot-ghci
GHCi, version 7.7.20121101: http://www.haskell.org/ghc/ :? for help
Loading package...```
$ ghc -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history T4012 --interactive -ignore-dot-ghci
GHCi, version 7.7.20121101: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
[1 of 3] Compiling T4012_B ( T4012_B.hs, interpreted )
ByteCodeLink: can't find label
During interactive linking, GHCi couldn't find the following symbol:
ghczuwrapperZC0ZCmainZCT4012zuBZCprintf
This may be due to you not asking GHCi to load extra object files,
archives or DLLs needed by your current session. Restart GHCi, specifying
the missing library using the -L/path/to/object/dir and -lmissinglibname
flags, or simply by naming the relevant files on the GHCi command line.
Alternatively, this link failure might indicate a bug in GHCi.
If you suspect the latter, please send a bug report to:
glasgow-haskell-bugs@haskell.org
>
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.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":"CAPI doesn't work with ghci","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"7.6.2","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"igloo"},"version":"7.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n$ ghc -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history T4012 --interactive -ignore-dot-ghci \r\nGHCi, version 7.7.20121101: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer-gmp ... linking ... done.\r\nLoading package base ... linking ... done.\r\n[1 of 3] Compiling T4012_B ( T4012_B.hs, interpreted )\r\n\r\nByteCodeLink: can't find label\r\nDuring interactive linking, GHCi couldn't find the following symbol:\r\n ghczuwrapperZC0ZCmainZCT4012zuBZCprintf\r\nThis may be due to you not asking GHCi to load extra object files,\r\narchives or DLLs needed by your current session. Restart GHCi, specifying\r\nthe missing library using the -L/path/to/object/dir and -lmissinglibname\r\nflags, or simply by naming the relevant files on the GHCi command line.\r\nAlternatively, this link failure might indicate a bug in GHCi.\r\nIf you suspect the latter, please send a bug report to:\r\n glasgow-haskell-bugs@haskell.org\r\n\r\n> \r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/14760Error reporting on obsolete file2022-10-07T13:27:32ZSylvain HenryError reporting on obsolete fileI have just had this warning:
```
Whatever.hs:41:1: warning: [-Wunused-imports]
The import of ‘Data.Map’ is redundant
except perhaps to import instances from ‘Data.Map’
To import instances alone, use: import Data.Map()
...I have just had this warning:
```
Whatever.hs:41:1: warning: [-Wunused-imports]
The import of ‘Data.Map’ is redundant
except perhaps to import instances from ‘Data.Map’
To import instances alone, use: import Data.Map()
|
41 | import Data.Foldable
| ^^^^^^^^^^^^^^^^^^^^^
```
This happens because the source file has been modified during the compilation: GHC shows an excerpt of the new file to report an error in the old file. Could we cache the old file somehow during the compilation to avoid this discrepancy?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.2 |
| 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":"Error reporting on obsolete file","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I have just had this warning:\r\n{{{\r\nWhatever.hs:41:1: warning: [-Wunused-imports]\r\n The import of ‘Data.Map’ is redundant\r\n except perhaps to import instances from ‘Data.Map’\r\n To import instances alone, use: import Data.Map()\r\n |\r\n41 | import Data.Foldable\r\n | ^^^^^^^^^^^^^^^^^^^^^\r\n}}}\r\n\r\nThis happens because the source file has been modified during the compilation: GHC shows an excerpt of the new file to report an error in the old file. Could we cache the old file somehow during the compilation to avoid this discrepancy?","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/15183Expose the SNat type and the natSing method2022-10-07T11:35:54ZDavid FeuerExpose the SNat type and the natSing methodCurrently, neither the `SNat` type nor the `natSing` method of `KnownNat` are exported from `GHC.TypeLits`. This is weird and awkward. There's no apparent reason not to expose the `SNat` *type*, although it may make sense not to expose i...Currently, neither the `SNat` type nor the `natSing` method of `KnownNat` are exported from `GHC.TypeLits`. This is weird and awkward. There's no apparent reason not to expose the `SNat` *type*, although it may make sense not to expose its definition. It also could possibly make sense not to expose the fact that `natSing` is a *method* of `KnownNat`, but there's no apparent reason not to export a function with its type. Can we just do those?
1. Export the `SNat` type.
1. Export a function with the type of `natSing`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Expose the SNat type and the natSing method","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Currently, neither the `SNat` type nor the `natSing` method of `KnownNat` are exported from `GHC.TypeLits`. This is weird and awkward. There's no apparent reason not to expose the `SNat` ''type'', although it may make sense not to expose its definition. It also could possibly make sense not to expose the fact that `natSing` is a ''method'' of `KnownNat`, but there's no apparent reason not to export a function with its type. Can we just do those?\r\n\r\n1. Export the `SNat` type.\r\n2. Export a function with the type of `natSing`.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/15543Binary crashes under dtrace2022-10-03T13:41:34ZLast GBinary crashes under dtraceWhen I'm trying to attach to the simple binary with DTrace command (`sudo dtrace -n 'pid$1:::' `ps aux | grep FibbSlow | grep -v grep | awk '{print $2}'` `) it crashes with various outcomes. This happens on both GHC 8.4.3 from `stack` an...When I'm trying to attach to the simple binary with DTrace command (`sudo dtrace -n 'pid$1:::' `ps aux | grep FibbSlow | grep -v grep | awk '{print $2}'` `) it crashes with various outcomes. This happens on both GHC 8.4.3 from `stack` and manually built ghc from the master branch.
Crashes:
```
lastg-mbp:t lastg$ ./FibbSlow.master 55
FibbSlow.master: internal error: scavenge: unimplemented/strange closure type 13369548 @ 0x420021abb0^[[B
(GHC version 8.7.20180817 for x86_64_apple_darwin)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
```
lastg-mbp:t lastg$ ./FibbSlow.stack.8.4 55
FibbSlow.stack.8.4: internal error: scavenge_one: strange object 13369548
(GHC version 8.4.3 for x86_64_apple_darwin)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Abort trap: 6
```
```
lastg-mbp:t lastg$ ./FibbSlow.stack.8.4 55
FibbSlow.stack.8.4: internal error: scavenge_one: strange object 13369548
(GHC version 8.4.3 for x86_64_apple_darwin)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Abort trap: 6
```
```
lastg-mbp:t lastg$ ./FibbSlow.stack.8.4 55
Segmentation fault: 11
```
Source code for the binary:
https://gist.github.com/last-g/cfddab60a8520eb51214ef2a7bc48ec2
<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 | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Binary crashes under dtrace","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"Research needed","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":["crash","dtrace,"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When I'm trying to attach to the simple binary with DTrace command ({{{sudo dtrace -n 'pid$1:::' `ps aux | grep FibbSlow | grep -v grep | awk '{print $2}'` }}}) it crashes with various outcomes. This happens on both GHC 8.4.3 from `stack` and manually built ghc from the master branch.\r\n\r\nCrashes:\r\n\r\n{{{\r\nlastg-mbp:t lastg$ ./FibbSlow.master 55\r\nFibbSlow.master: internal error: scavenge: unimplemented/strange closure type 13369548 @ 0x420021abb0^[[B\r\n (GHC version 8.7.20180817 for x86_64_apple_darwin)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\n{{{\r\nlastg-mbp:t lastg$ ./FibbSlow.stack.8.4 55\r\nFibbSlow.stack.8.4: internal error: scavenge_one: strange object 13369548\r\n (GHC version 8.4.3 for x86_64_apple_darwin)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\nAbort trap: 6\r\n}}}\r\n\r\n{{{\r\nlastg-mbp:t lastg$ ./FibbSlow.stack.8.4 55\r\nFibbSlow.stack.8.4: internal error: scavenge_one: strange object 13369548\r\n (GHC version 8.4.3 for x86_64_apple_darwin)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\nAbort trap: 6\r\n}}}\r\n\r\n{{{\r\nlastg-mbp:t lastg$ ./FibbSlow.stack.8.4 55\r\nSegmentation fault: 11\r\n}}}\r\n\r\nSource code for the binary:\r\nhttps://gist.github.com/last-g/cfddab60a8520eb51214ef2a7bc48ec2","type_of_failure":"OtherFailure","blocking":[]} -->Research neededhttps://gitlab.haskell.org/ghc/ghc/-/issues/14098Incorrect pattern match warning on nested GADTs2022-09-30T18:20:38ZjmgrosenIncorrect pattern match warning on nested GADTs```hs
{-# Language GADTs #-}
data App f a where
App :: f a -> App f (Maybe a)
data Ty a where
TBool :: Ty Bool
TInt :: Ty Int
data T f a where
C :: T Ty (Maybe Bool)
-- Warning
f :: T f a -> App f a -> ()
f C (App TBool) = (...```hs
{-# Language GADTs #-}
data App f a where
App :: f a -> App f (Maybe a)
data Ty a where
TBool :: Ty Bool
TInt :: Ty Int
data T f a where
C :: T Ty (Maybe Bool)
-- Warning
f :: T f a -> App f a -> ()
f C (App TBool) = ()
-- No warning
g :: T f a -> App f a -> ()
g C (App x) = case x of
TBool -> ()
```
When compiling, with `-Wincomplete-patterns`:
```
Foo.hs:15:1: warning: [-Wincomplete-patterns]
Pattern match(es) are non-exhaustive
In an equation for ‘f’: Patterns not matched: C (App TInt)
|
15 | f C (App TBool) = ()
| ^^^^^^^^^^^^^^^^^^^^
```
I'm sorry for such a complicated example, but I wasn't able to reduce it any further than this.
The gist of the problem is that this code gives a pattern matching non-exhaustiveness warning when matching a nested pattern, when pulling out a value then matching on it produces no warning (correctly). It also seems to have to do with using a type constructor (`Maybe`) within the constructor definition of `App`, as changing it to
```hs
data App f a where
App :: f a -> App f a
...
data T f a where
C :: T Ty Bool
```
does not give a warning, even when `App` is modified further to force it to be a proper GADT.
This might be a known limitation of the checker, but given that it works fine when the nesting is removed, I would think it would be more of a bug.
Thanks to Iavor for helping me minimize the test case.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | diatchki |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Incorrect pattern match warning on nested GADTs","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":["PatternMatchWarnings"],"differentials":[],"test_case":"","architecture":"","cc":["diatchki"],"type":"Bug","description":"{{{#!hs\r\n{-# Language GADTs #-}\r\n\r\ndata App f a where\r\n App :: f a -> App f (Maybe a)\r\n\r\ndata Ty a where\r\n TBool :: Ty Bool\r\n TInt :: Ty Int\r\n\r\ndata T f a where\r\n C :: T Ty (Maybe Bool)\r\n\r\n-- Warning\r\nf :: T f a -> App f a -> ()\r\nf C (App TBool) = ()\r\n\r\n-- No warning\r\ng :: T f a -> App f a -> ()\r\ng C (App x) = case x of\r\n TBool -> ()\r\n}}}\r\n\r\nWhen compiling, with `-Wincomplete-patterns`:\r\n{{{\r\nFoo.hs:15:1: warning: [-Wincomplete-patterns]\r\n Pattern match(es) are non-exhaustive\r\n In an equation for ‘f’: Patterns not matched: C (App TInt)\r\n |\r\n15 | f C (App TBool) = ()\r\n | ^^^^^^^^^^^^^^^^^^^^\r\n}}}\r\n\r\nI'm sorry for such a complicated example, but I wasn't able to reduce it any further than this.\r\n\r\nThe gist of the problem is that this code gives a pattern matching non-exhaustiveness warning when matching a nested pattern, when pulling out a value then matching on it produces no warning (correctly). It also seems to have to do with using a type constructor (`Maybe`) within the constructor definition of `App`, as changing it to\r\n{{{#!hs\r\ndata App f a where\r\n App :: f a -> App f a\r\n\r\n...\r\n\r\ndata T f a where\r\n C :: T Ty Bool\r\n}}}\r\ndoes not give a warning, even when `App` is modified further to force it to be a proper GADT.\r\n\r\nThis might be a known limitation of the checker, but given that it works fine when the nesting is removed, I would think it would be more of a bug.\r\n\r\nThanks to Iavor for helping me minimize the test case.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/16335CPR Analysis is too conservative for certain inductive cases2022-09-27T09:02:04ZSebastian GrafCPR Analysis is too conservative for certain inductive casesWhile investigating the generated Core for a simple toy benchmark, I came up with the following minimal example:
```hs
data Expr
= Lit Int
| Plus Expr Expr
eval :: Expr -> Int
eval (Lit n) = n
eval (Plus a b) = eval a + eval b
```
...While investigating the generated Core for a simple toy benchmark, I came up with the following minimal example:
```hs
data Expr
= Lit Int
| Plus Expr Expr
eval :: Expr -> Int
eval (Lit n) = n
eval (Plus a b) = eval a + eval b
```
resulting in the following Core:
```
eval
= \ (ds_d112 :: Expr) ->
case ds_d112 of {
Lit n_aXf -> n_aXf;
Plus a_aXg b_aXh ->
case eval a_aXg of { GHC.Types.I# x_a1bK ->
case eval b_aXh of { GHC.Types.I# y_a1bO ->
GHC.Types.I# (GHC.Prim.+# x_a1bK y_a1bO)
}
}
}
```
Note that this needlessly unboxes and boxes primitive Ints. Lifting this is precisely the job of CPR, but `eval` doesn't exactly have the CPR property: the `Lit` case doesn't return a product. But we're punishing ourselves for the base case when *even the function itself* recurses multiple times!
The code resulting from WWing here wouldn't even look bad in the `Lit` case:
```
Foo.$weval
= \ (w_s1cn :: Expr) ->
case w_s1cn of {
Lit dt_d11b -> case dt_d11b { I# ds_abcd -> ds_abcd };
Plus a_aXf b_aXg ->
case Foo.$weval a_aXf of ww_s1cq { __DEFAULT ->
case Foo.$weval b_aXg of ww1_X1dh { __DEFAULT ->
GHC.Prim.+# ww_s1cq ww1_X1dh
}
}
}
eval
= \ (w_s1cn :: Expr) ->
case Foo.$weval w_s1cn of ww_s1cq { __DEFAULT ->
GHC.Types.I# ww_s1cq
}
```
Granted, this is bad for the case where there is no recursion happening and we need the result of `eval` boxed, but that's a small price to pay IMO.
I begin to think of CPR more of as the "dual" to SpecConstr than to Strictness Analysis. Return pattern specialisation, so to speak.
-----
I'll add some more examples here when such a return-pattern specialisation might be useful.
- Nested CPR may not unbox if termination of nested components doesn't permit it to. We leave a -17% improvement in `fish` on the table [here](https://gitlab.haskell.org/ghc/ghc/-/merge_requests/1866#note_272983).
- #4267
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.3 |
| 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":"Make CPR Analysis more aggressive for inductive cases","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"⊥","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":["CPRAnalysis"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"While investigating the generated Core for a simple toy benchmark, I came up with the following minimal example:\r\n\r\n{{{#!hs\r\n\r\ndata Expr\r\n = Lit Int\r\n | Plus Expr Expr\r\n\r\neval :: Expr -> Int\r\neval (Lit n) = n\r\neval (Plus a b) = eval a + eval b\r\n}}}\r\n\r\nresulting in the following Core:\r\n\r\n{{{\r\neval\r\n = \\ (ds_d112 :: Expr) ->\r\n case ds_d112 of {\r\n Lit n_aXf -> n_aXf;\r\n Plus a_aXg b_aXh ->\r\n case eval a_aXg of { GHC.Types.I# x_a1bK ->\r\n case eval b_aXh of { GHC.Types.I# y_a1bO ->\r\n GHC.Types.I# (GHC.Prim.+# x_a1bK y_a1bO)\r\n }\r\n }\r\n }\r\n}}}\r\n\r\nNote that this needlessly unboxes and boxes primitive Ints. Lifting this is precisely the job of CPR, but `eval` doesn't exactly have the CPR property: the `Lit` case doesn't return a product. But we're punishing ourselves for the base case when ''even the function itself'' recurses multiple times!\r\n\r\nThe code resulting from WWing here wouldn't even look bad in the `Lit` case:\r\n\r\n{{{\r\nFoo.$weval\r\n = \\ (w_s1cn :: Expr) ->\r\n case w_s1cn of {\r\n Lit dt_d11b -> case dt_d11b { I# ds_abcd -> ds_abcd };\r\n Plus a_aXf b_aXg ->\r\n case Foo.$weval a_aXf of ww_s1cq { __DEFAULT ->\r\n case Foo.$weval b_aXg of ww1_X1dh { __DEFAULT ->\r\n GHC.Prim.+# ww_s1cq ww1_X1dh\r\n }\r\n }\r\n }\r\n\r\neval\r\n = \\ (w_s1cn :: Expr) ->\r\n case Foo.$weval w_s1cn of ww_s1cq { __DEFAULT ->\r\n GHC.Types.I# ww_s1cq\r\n }\r\n}}}\r\n\r\nGranted, this is bad for the case where there is no recursion happening and we need the result of `eval` boxed, but that's a small price to pay IMO.\r\n\r\nI begin to think of CPR more of as the \"dual\" to SpecConstr than to Strictness Analysis. Return pattern specialisation, so to speak.","type_of_failure":"OtherFailure","blocking":[]} -->⊥https://gitlab.haskell.org/ghc/ghc/-/issues/1171GHC doesn't respect the imprecise exceptions semantics2022-09-26T16:09:03ZneilGHC doesn't respect the imprecise exceptions semanticsYhc bug 122 appears to be a GHC bug: http://code.google.com/p/yhc/issues/detail?id=122 , discussed here: http://thread.gmane.org/gmane.comp.lang.haskell.yhc/720
To reproduce:
Download and install Yhc two separate times, once doing "scon...Yhc bug 122 appears to be a GHC bug: http://code.google.com/p/yhc/issues/detail?id=122 , discussed here: http://thread.gmane.org/gmane.comp.lang.haskell.yhc/720
To reproduce:
Download and install Yhc two separate times, once doing "scons" to build, once doing "scons type=release". Follow the steps outlined in the above bug report with the standard version, and it gives the correct behaviour. Try again with the release version and it gives the wrong behaviour. GHC 6.4.2 works fine. The difference between the two is that type=release builds with -O, normal doesn't.
Changing the code slightly, by introducing "obvious" assert statements in Package.hs makes the bug go away. Creating reduced tests cases didn't get very far...
This has been replicated on Mac and Windows with GHC 6.6. If you have any further questions about the code then feel free to email me or the Yhc list. Marking as severity=major because silently doing something different is about as bad as they come.
Thanks to Thorkil for doing the detective work to track this down as far as GHC.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.6 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Multiple |
| Architecture | Multiple |
</details>
<!-- {"blocked_by":[],"summary":"GHC generates incorrect code with -O for Haskell 98 program","status":"New","operating_system":"Multiple","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6","keywords":[],"differentials":[],"test_case":"","architecture":"Multiple","cc":[""],"type":"Bug","description":"Yhc bug 122 appears to be a GHC bug: http://code.google.com/p/yhc/issues/detail?id=122 , discussed here: http://thread.gmane.org/gmane.comp.lang.haskell.yhc/720\r\n\r\nTo reproduce:\r\nDownload and install Yhc two separate times, once doing \"scons\" to build, once doing \"scons type=release\". Follow the steps outlined in the above bug report with the standard version, and it gives the correct behaviour. Try again with the release version and it gives the wrong behaviour. GHC 6.4.2 works fine. The difference between the two is that type=release builds with -O, normal doesn't.\r\n\r\nChanging the code slightly, by introducing \"obvious\" assert statements in Package.hs makes the bug go away. Creating reduced tests cases didn't get very far...\r\n\r\nThis has been replicated on Mac and Windows with GHC 6.6. If you have any further questions about the code then feel free to email me or the Yhc list. Marking as severity=major because silently doing something different is about as bad as they come.\r\n\r\nThanks to Thorkil for doing the detective work to track this down as far as GHC.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/8441Allow family instances in an hs-boot file2022-09-21T15:53:16ZRichard Eisenbergrae@richarde.devAllow family instances in an hs-boot fileCompiling an .hs-boot file with a data instance leads to this error:
```
Illegal family instance in hs-boot file
```
Yet, data instances make good sense in an hs-boot file, in case another module wants to access a constructor decla...Compiling an .hs-boot file with a data instance leads to this error:
```
Illegal family instance in hs-boot file
```
Yet, data instances make good sense in an hs-boot file, in case another module wants to access a constructor declared in the instance.
Furthermore, it may sometimes be desirable to allow type family instances in a hs-boot file, as well, in case some including modules need the instance for type simplification.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.7 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Allow family instances in an hs-boot file","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Compiling an .hs-boot file with a data instance leads to this error:\r\n\r\n{{{\r\n Illegal family instance in hs-boot file\r\n}}}\r\n\r\nYet, data instances make good sense in an hs-boot file, in case another module wants to access a constructor declared in the instance.\r\n\r\nFurthermore, it may sometimes be desirable to allow type family instances in a hs-boot file, as well, in case some including modules need the instance for type simplification.","type_of_failure":"OtherFailure","blocking":[]} -->Edward Z. YangEdward Z. Yanghttps://gitlab.haskell.org/ghc/ghc/-/issues/16278Exhaustivity checking GADT with free variables2022-09-20T17:28:38ZAndrew MartinExhaustivity checking GADT with free variablesConsider the following example:
```hs
{-# language DataKinds #-}
{-# language TypeFamilies #-}
{-# language GADTs #-}
{-# language KindSignatures #-}
{-# OPTIONS_GHC -Wall -fforce-recomp #-}
module GadtException where
import Data.Kin...Consider the following example:
```hs
{-# language DataKinds #-}
{-# language TypeFamilies #-}
{-# language GADTs #-}
{-# language KindSignatures #-}
{-# OPTIONS_GHC -Wall -fforce-recomp #-}
module GadtException where
import Data.Kind (Type)
import GHC.Exts
data Send = Send
data SocketException :: Send -> Type where
LocalShutdown :: SocketException 'Send
OutOfMemory :: SocketException a
someSocketException :: SocketException a
someSocketException = OutOfMemory
foo :: Int
foo = case someSocketException :: SocketException Any of
LocalShutdown -> 2
OutOfMemory -> 1
```
In `foo`, GHC's exhaustivity checker requires a pattern match on `LocalShutdown`. However, `LocalShutdown` is not an inhabitant of `SocketException Any`. What I would really like is for this to go one step further. I shouldn't even need to write the type annotation. That is, with the above code otherwise unchanged, GHC should recognize that
```hs
foo :: Int
foo = case someSocketException of
OutOfMemory -> 1
```
handles all possible cases. Since fully polymorphic type variables become `Any` at some point during typechecking, I would expect that if this worked with the `SocketException Any` type signature, it would work without it.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.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":"Exhaustivity checking GADT with free variables","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":"Consider the following example:\r\n\r\n{{{#!hs\r\n{-# language DataKinds #-}\r\n{-# language TypeFamilies #-}\r\n{-# language GADTs #-}\r\n{-# language KindSignatures #-}\r\n\r\n{-# OPTIONS_GHC -Wall -fforce-recomp #-}\r\n\r\nmodule GadtException where\r\n\r\nimport Data.Kind (Type)\r\nimport GHC.Exts\r\n\r\ndata Send = Send\r\n\r\ndata SocketException :: Send -> Type where \r\n LocalShutdown :: SocketException 'Send\r\n OutOfMemory :: SocketException a\r\n\r\nsomeSocketException :: SocketException a\r\nsomeSocketException = OutOfMemory\r\n\r\nfoo :: Int\r\nfoo = case someSocketException :: SocketException Any of\r\n LocalShutdown -> 2\r\n OutOfMemory -> 1\r\n}}}\r\n\r\nIn `foo`, GHC's exhaustivity checker requires a pattern match on `LocalShutdown`. However, `LocalShutdown` is not an inhabitant of `SocketException Any`. What I would really like is for this to go one step further. I shouldn't even need to write the type annotation. That is, with the above code otherwise unchanged, GHC should recognize that\r\n\r\n{{{#!hs\r\nfoo :: Int\r\nfoo = case someSocketException of\r\n OutOfMemory -> 1\r\n}}}\r\n\r\nhandles all possible cases. Since fully polymorphic type variables become `Any` at some point during typechecking, I would expect that if this worked with the `SocketException Any` type signature, it would work without it.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12114Make injectivity check less conservative2022-09-20T17:28:38ZMikeIzbickiMake injectivity check less conservativeThe following injective type family fails to compile in GHC 8.0
```
type family Snoc (xs :: [k]) (y::k) = r | r -> xs y where
Snoc '[] y = '[y]
Snoc (x ': xs) y = x ': (Snoc xs y)
```
The error message is
```
• Type ...The following injective type family fails to compile in GHC 8.0
```
type family Snoc (xs :: [k]) (y::k) = r | r -> xs y where
Snoc '[] y = '[y]
Snoc (x ': xs) y = x ': (Snoc xs y)
```
The error message is
```
• Type family equations violate injectivity annotation:
forall k (y :: k). Snoc '[] y = '[y] -- Defined at FAlgebra.hs:49:5
forall k (xs :: [k]) (x :: k) (y :: k).
Snoc (x : xs) y = x : Snoc xs y -- Defined at FAlgebra.hs:52:5
• In the equations for closed type family ‘Snoc’
In the type family declaration for ‘Snoc’
```
I think the problem is related to injectivity rule 5 from \[this page\](https://ghc.haskell.org/trac/ghc/wiki/InjectiveTypeFamilies) being too conservative. In particular, if you substitute `'[]` for `Snoc xs y` in the RHS of the second rule, then the two rules will unify but have different LHSs. This substitution is invalid, however, because the `Snoc` type family will never result in an empty list.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC rejects injective type family","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following injective type family fails to compile in GHC 8.0\r\n\r\n{{{\r\ntype family Snoc (xs :: [k]) (y::k) = r | r -> xs y where\r\n Snoc '[] y = '[y]\r\n Snoc (x ': xs) y = x ': (Snoc xs y)\r\n}}}\r\n\r\nThe error message is\r\n\r\n{{{\r\n • Type family equations violate injectivity annotation:\r\n forall k (y :: k). Snoc '[] y = '[y] -- Defined at FAlgebra.hs:49:5\r\n forall k (xs :: [k]) (x :: k) (y :: k).\r\n Snoc (x : xs) y = x : Snoc xs y -- Defined at FAlgebra.hs:52:5\r\n • In the equations for closed type family ‘Snoc’\r\n In the type family declaration for ‘Snoc’\r\n}}}\r\n\r\nI think the problem is related to injectivity rule 5 from [this page](https://ghc.haskell.org/trac/ghc/wiki/InjectiveTypeFamilies) being too conservative. In particular, if you substitute `'[]` for `Snoc xs y` in the RHS of the second rule, then the two rules will unify but have different LHSs. This substitution is invalid, however, because the `Snoc` type family will never result in an empty list.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14046“Illegal type synonym family application in instance” is too strict in the pr...2022-09-20T15:26:38ZAlexis King“Illegal type synonym family application in instance” is too strict in the presence of functional dependenciesGHC rejects the following instance, complaining about the use of a type synonym family in the instance head:
```hs
type family Fam a
class Multi a b | a -> b
instance Multi (Maybe a) (Fam a)
```
However, this seems too strict to me, si...GHC rejects the following instance, complaining about the use of a type synonym family in the instance head:
```hs
type family Fam a
class Multi a b | a -> b
instance Multi (Maybe a) (Fam a)
```
However, this seems too strict to me, since the second parameter of `Multi` is determined by a functional dependency. If I tweak the instance slightly to lift the second parameter out of the instance head into an equality constraint, GHC accepts the instance:
```hs
instance (b ~ Fam a) => Multi (Maybe a) b
```
It seems to me that, due to the functional dependency, these two instances are completely equivalent. Therefore, GHC should accept the first instance.
This is similar to an old ticket, #3485, but that did not involve fundeps, so GHC’s error was correct. I’m pretty sure the addition of functional dependencies changes things, making the two actually equivalent.
<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":"“Illegal type synonym family application in instance” is too strict in the presence of functional dependencies","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":"GHC rejects the following instance, complaining about the use of a type synonym family in the instance head:\r\n\r\n{{{#!hs\r\ntype family Fam a\r\nclass Multi a b | a -> b\r\ninstance Multi (Maybe a) (Fam a)\r\n}}}\r\n\r\nHowever, this seems too strict to me, since the second parameter of `Multi` is determined by a functional dependency. If I tweak the instance slightly to lift the second parameter out of the instance head into an equality constraint, GHC accepts the instance:\r\n\r\n{{{#!hs\r\ninstance (b ~ Fam a) => Multi (Maybe a) b\r\n}}}\r\n\r\nIt seems to me that, due to the functional dependency, these two instances are completely equivalent. Therefore, GHC should accept the first instance.\r\n\r\nThis is similar to an old ticket, #3485, but that did not involve fundeps, so GHC’s error was correct. I’m pretty sure the addition of functional dependencies changes things, making the two actually equivalent.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/11012Support for unicode primes on identifiers.2022-09-20T12:03:01ZghartshawSupport for unicode primes on identifiers.GHC should allow the (single/double/triple/quadruple) prime characters in Unicode to be allowed in identifiers. This would make them consistent with the ASCII apostrophe, which is usually used in place of a single prime. The current work...GHC should allow the (single/double/triple/quadruple) prime characters in Unicode to be allowed in identifiers. This would make them consistent with the ASCII apostrophe, which is usually used in place of a single prime. The current workaround for primes (using one or more apostrophes) is unwieldy for higher primes (e.g. `a'''` and `a''''`).
All of the following identifiers should be valid.
```
a' // U+0027 APOSTROPHE
a′ // U+2032 PRIME
a″ // U+2033 DOUBLE PRIME
a‴ // U+2034 TRIPLE PRIME
a⁗ // U+2057 QUADRUPLE PRIME
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 7.10.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Compiler (Parser) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Support for unicode primes on identifiers.","status":"New","operating_system":"","component":"Compiler (Parser)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"GHC should allow the (single/double/triple/quadruple) prime characters in Unicode to be allowed in identifiers. This would make them consistent with the ASCII apostrophe, which is usually used in place of a single prime. The current workaround for primes (using one or more apostrophes) is unwieldy for higher primes (e.g. {{{a'''}}} and {{{a''''}}}).\r\n\r\nAll of the following identifiers should be valid.\r\n{{{\r\na' // U+0027 APOSTROPHE\r\na′ // U+2032 PRIME\r\na″ // U+2033 DOUBLE PRIME\r\na‴ // U+2034 TRIPLE PRIME\r\na⁗ // U+2057 QUADRUPLE PRIME\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/404Double constant leads to malformed .hc2022-09-20T07:50:50ZManuel M T ChakravartyDouble constant leads to malformed .hc```
The program
> avogadro = 6.022E23
> main = print $ avogadro
when compiled with -O leads to a .hc about which gcc
complains
Main.hc: In function 'Main_lvl_entry':
Main.hc:328: warning: integer overflow in expression
The .hc fi...```
The program
> avogadro = 6.022E23
> main = print $ avogadro
when compiled with -O leads to a .hc about which gcc
complains
Main.hc: In function 'Main_lvl_entry':
Main.hc:328: warning: integer overflow in expression
The .hc files is attached.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Double constant leads to malformed .hc","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"6.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nThe program\n\n> avogadro = 6.022E23\n> main = print $ avogadro\n\nwhen compiled with -O leads to a .hc about which gcc\ncomplains\n\n Main.hc: In function 'Main_lvl_entry':\n Main.hc:328: warning: integer overflow in expression\n\nThe .hc files is attached. \n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/15252syn_arg_wraps and syn_res_wrap are only populated after typechecking2022-09-19T19:52:04ZMatthew Pickeringsyn_arg_wraps and syn_res_wrap are only populated after typecheckingThe definition for `SyntaxExpr` has two fields which are only populated after type checking. `SyntaxExpr` should have an extension point which contains these two fields.
```
data SyntaxExpr p = SyntaxExpr { syn_expr :: HsExpr p ...The definition for `SyntaxExpr` has two fields which are only populated after type checking. `SyntaxExpr` should have an extension point which contains these two fields.
```
data SyntaxExpr p = SyntaxExpr { syn_expr :: HsExpr p
, syn_arg_wraps :: [HsWrapper]
, syn_res_wrap :: HsWrapper }
```
<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 | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"syn_arg_wraps and syn_res_wrap are only populated after typechecking","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":["newcomer"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The definition for `SyntaxExpr` has two fields which are only populated after type checking. `SyntaxExpr` should have an extension point which contains these two fields.\r\n\r\n{{{\r\n data SyntaxExpr p = SyntaxExpr { syn_expr :: HsExpr p \r\n , syn_arg_wraps :: [HsWrapper] \r\n , syn_res_wrap :: HsWrapper } \r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/11499Loading temp shared object failed in GHCi2022-09-17T09:07:25Zalfa07Loading temp shared object failed in GHCiWhile trying to launch ghci got the following error:
```
❯ stack ghci
The following GHC options are incompatible with GHCi and have not been passed to it: -threaded -Odph
Using main module: 1. Package `line-segment-intersection' compone...While trying to launch ghci got the following error:
```
❯ stack ghci
The following GHC options are incompatible with GHCi and have not been passed to it: -threaded -Odph
Using main module: 1. Package `line-segment-intersection' component exe:demo with main-is file: /Users/maxim/Dev/ComputationGeometry/LineSegmentIntersection/app/Main.hs
Configuring GHCi with the following packages: line-segment-intersection, GLUT, GLUtil, boundingboxes, freetype-simple, freetype2
GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help
ghc: panic! (the 'impossible' happened)
(GHC version 7.10.3 for x86_64-apple-darwin):
Loading temp shared object failed: dlopen(/var/folders/dz/lm9jncs90nq0vn_5j7xhpg2xqyfj66/T/ghc23900_0/libghc_25.dylib, 5): Symbol not found: _bdf_driver_class
Referenced from: /var/folders/dz/lm9jncs90nq0vn_5j7xhpg2xqyfj66/T/ghc23900_0/libghc_25.dylib
Expected in: flat namespace
in /var/folders/dz/lm9jncs90nq0vn_5j7xhpg2xqyfj66/T/ghc23900_0/libghc_25.dylib
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```https://gitlab.haskell.org/ghc/ghc/-/issues/13511ApplicativeDo return case doesn't handle lets2022-09-16T23:26:30ZmnislaihApplicativeDo return case doesn't handle letsWe ran into this bug in production, this is a simplified reproduction. The following program will not type check, requiring an unnecessary Monad instance:
```
{-# LANGUAGE ApplicativeDo, GeneralizedNewtypeDeriving #-}
import Data.Funct...We ran into this bug in production, this is a simplified reproduction. The following program will not type check, requiring an unnecessary Monad instance:
```
{-# LANGUAGE ApplicativeDo, GeneralizedNewtypeDeriving #-}
import Data.Functor.Identity
import Data.Monoid
newtype A x = A (Identity x) deriving (Functor, Applicative)
shouldWork :: A ()
shouldWork = do
a <- pure ()
b <- pure ()
let ab = a <> b
return ab
```
```
pepe:~/code/snippets$ ghci ApplicativeDoBug.hs
GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Main ( ApplicativeDoBug.hs, interpreted )
ApplicativeDoBug.hs:10:14: error:
• No instance for (Monad A) arising from a do statement
• In the expression:
do { a <- pure ();
b <- pure ();
let ab = a <> b;
return ab }
In an equation for ‘shouldWork’:
shouldWork
= do { a <- pure ();
b <- pure ();
let ab = ...;
return ab }
Failed, modules loaded: none.
```
There is a simple workaround, which worked for us in production:
```
workaround :: A ()
workaround = do
a <- pure ()
b <- pure ()
return $
let ab = a <> b
in ab
```
I asked in \#ghc and it seems this is not yet fixed in HEAD.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.2 |
| 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":"ApplicativeDo incorrectly requiring Monad","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"We ran into this bug in production, this is a simplified reproduction. The following program will not type check, requiring an unnecessary Monad instance:\r\n\r\n{{{\r\n{-# LANGUAGE ApplicativeDo, GeneralizedNewtypeDeriving #-}\r\n\r\nimport Data.Functor.Identity\r\nimport Data.Monoid\r\n\r\nnewtype A x = A (Identity x) deriving (Functor, Applicative)\r\n\r\nshouldWork :: A ()\r\nshouldWork = do\r\n a <- pure ()\r\n b <- pure ()\r\n let ab = a <> b\r\n return ab\r\n}}}\r\n\r\n{{{\r\npepe:~/code/snippets$ ghci ApplicativeDoBug.hs \r\nGHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help\r\n[1 of 1] Compiling Main ( ApplicativeDoBug.hs, interpreted )\r\n\r\nApplicativeDoBug.hs:10:14: error:\r\n • No instance for (Monad A) arising from a do statement\r\n • In the expression:\r\n do { a <- pure ();\r\n b <- pure ();\r\n let ab = a <> b;\r\n return ab }\r\n In an equation for ‘shouldWork’:\r\n shouldWork\r\n = do { a <- pure ();\r\n b <- pure ();\r\n let ab = ...;\r\n return ab }\r\nFailed, modules loaded: none.\r\n}}}\r\n\r\nThere is a simple workaround, which worked for us in production:\r\n{{{\r\nworkaround :: A ()\r\nworkaround = do\r\n a <- pure ()\r\n b <- pure ()\r\n return $\r\n let ab = a <> b\r\n in ab\r\n}}}\r\n\r\nI asked in #ghc and it seems this is not yet fixed in HEAD.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/522String gap failure not due to cpp2022-09-12T09:10:00ZmorabbinString gap failure not due to cpp```
Have you tried StringGapBug2.hs that I sent in? With
my setup (vanilla 4.08.2) it fails even without -cpp.
The command line I use is:
ghc-4.08.2 -c StringGapBug2.hs
and I get the following error:
StringGapBug2.hs:27: err...```
Have you tried StringGapBug2.hs that I sent in? With
my setup (vanilla 4.08.2) it fails even without -cpp.
The command line I use is:
ghc-4.08.2 -c StringGapBug2.hs
and I get the following error:
StringGapBug2.hs:27: error in character literal
I've had a quick look at Lex.lexstringgap and there
doesn't seem to be any problem there (I had thought
that the second \ may have been kept in the lexeme
when starting to lex the string again, but that
doesn't seem to be the case).
I've attached StringGapBug2.hs again.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | None |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedDuplicate |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"String gap failure not due to cpp","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"ResolvedDuplicate","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"None","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nHave you tried StringGapBug2.hs that I sent in? With \nmy setup (vanilla 4.08.2) it fails even without -cpp.\nThe command line I use is:\n\n ghc-4.08.2 -c StringGapBug2.hs\n\nand I get the following error:\n\n StringGapBug2.hs:27: error in character literal\n\nI've had a quick look at Lex.lexstringgap and there \ndoesn't seem to be any problem there (I had thought \nthat the second \\ may have been kept in the lexeme \nwhen starting to lex the string again, but that \ndoesn't seem to be the case).\n\nI've attached StringGapBug2.hs again.\n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/43Parallel!2022-09-12T09:10:00ZnobodyParallel!```
I tried to compile a program using the library
parallel, but i don't get
it!
I put the errors messages in a final of tjis message
I use :
Llinux RedHat 7.1
PVM 3.4.3
GHC 5.02.1
(instaled by ghc-5.02.1.rh71-1.i386.rpm, ghc-
prof.02...```
I tried to compile a program using the library
parallel, but i don't get
it!
I put the errors messages in a final of tjis message
I use :
Llinux RedHat 7.1
PVM 3.4.3
GHC 5.02.1
(instaled by ghc-5.02.1.rh71-1.i386.rpm, ghc-
prof.02.1.rh71-1.i386.rpm
and ghc-doc-5.02.1-rh71-i386.rpm)
the computers are:
Athlon 1.2 Ghz
Hd 40 Gb
512 memory
mainboard Pcchips 810
and
Pentium II 400 Mhz
Hd 20 Gb
256 memory
mainboard PCchips M748 lmrt
I need a Help, I think that it's wanting anything, but
I don't know
what!
Thank's a lot!
Marcelo de Souza Sampaio
marcsam@iprj.uerj.br
ghc -parallel -package concurrent -o unidimensional1
unidimensional.hs
unidimensional.hs:2:
failed to load interface for `Prelude':
Could not find interface file for `Prelude'
unidimensional.hs:4:
failed to load interface for `Parallel':
Could not find interface file for `Parallel'
unidimensional.hs:5:
failed to load interface for `Strategies':
Could not find interface file for `Strategies'
unidimensional.hs:6:
failed to load interface for `Random':
Could not find interface file for `Random'
unidimensional.hs:8:
failed to load interface for `PrelReal':
Could not find interface file for `PrelReal'
unidimensional.hs:9:
failed to load interface for `PrelIOBase':
Could not find interface file for `PrelIOBase'
[mlbarros@luiza /tmp]$
ghc -i/usr/lib/ghc-5.0201/imports/std:/usr/lib/ghc-
5.0201/imports/concurrent -package concurrent -
parallel -o unidimensional2 unidimensional.hs
unidimensional.hs:2:
failed to load interface for `Prelude':
Could not find interface file for `Prelude'
unidimensional.hs:4:
failed to load interface for `Parallel':
Could not find interface file for `Parallel'
unidimensional.hs:5:
failed to load interface for `Strategies':
Could not find interface file for `Strategies'
unidimensional.hs:6:
failed to load interface for `Random':
Could not find interface file for `Random'
unidimensional.hs:8:
failed to load interface for `PrelReal':
Could not find interface file for `PrelReal'
unidimensional.hs:9:
failed to load interface for `PrelIOBase':
Could not find interface file for `PrelIOBase'
[mlbarros@luiza /tmp]$
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | None |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedNoReason |
| Component | None |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Parallel!","status":"New","operating_system":"","component":"None","related":[],"milestone":"","resolution":"ResolvedNoReason","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"None","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nI tried to compile a program using the library \nparallel, but i don't get\nit!\n\nI put the errors messages in a final of tjis message\n\nI use :\nLlinux RedHat 7.1\nPVM 3.4.3\nGHC 5.02.1\n(instaled by ghc-5.02.1.rh71-1.i386.rpm, ghc-\nprof.02.1.rh71-1.i386.rpm\nand ghc-doc-5.02.1-rh71-i386.rpm)\n\n the computers are:\nAthlon 1.2 Ghz\nHd 40 Gb\n512 memory\nmainboard Pcchips 810\nand\nPentium II 400 Mhz\nHd 20 Gb\n256 memory\nmainboard PCchips M748 lmrt\n\nI need a Help, I think that it's wanting anything, but \nI don't know\nwhat!\n\nThank's a lot!\n\nMarcelo de Souza Sampaio\nmarcsam@iprj.uerj.br\n\n\n\n\n ghc -parallel -package concurrent -o unidimensional1 \nunidimensional.hs\n\nunidimensional.hs:2:\n failed to load interface for `Prelude':\n Could not find interface file for `Prelude'\n \nunidimensional.hs:4:\n failed to load interface for `Parallel':\n Could not find interface file for `Parallel'\n \nunidimensional.hs:5:\n failed to load interface for `Strategies':\n Could not find interface file for `Strategies'\n \nunidimensional.hs:6:\n failed to load interface for `Random':\n Could not find interface file for `Random'\n \nunidimensional.hs:8:\n failed to load interface for `PrelReal':\n Could not find interface file for `PrelReal'\n \nunidimensional.hs:9:\n failed to load interface for `PrelIOBase':\n Could not find interface file for `PrelIOBase'\n[mlbarros@luiza /tmp]$\n\n ghc -i/usr/lib/ghc-5.0201/imports/std:/usr/lib/ghc-\n5.0201/imports/concurrent -package concurrent -\nparallel -o unidimensional2 unidimensional.hs\n\nunidimensional.hs:2:\n failed to load interface for `Prelude':\n Could not find interface file for `Prelude'\n \nunidimensional.hs:4:\n failed to load interface for `Parallel':\n Could not find interface file for `Parallel'\n \nunidimensional.hs:5:\n failed to load interface for `Strategies':\n Could not find interface file for `Strategies'\n \nunidimensional.hs:6:\n failed to load interface for `Random':\n Could not find interface file for `Random'\n \nunidimensional.hs:8:\n failed to load interface for `PrelReal':\n Could not find interface file for `PrelReal'\n \nunidimensional.hs:9:\n failed to load interface for `PrelIOBase':\n Could not find interface file for `PrelIOBase'\n[mlbarros@luiza /tmp]$\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/12483Improve parse error message on indentation mistake2022-09-12T03:30:05ZharendraImprove parse error message on indentation mistakeConsider the following code fragment:
```hs
(ExecGhc, args) -> execCompiler "" args
-- NOTE: this won't currently work for GHCJS, because it doesn't have
-- a runghcjs binary. I...Consider the following code fragment:
```hs
(ExecGhc, args) -> execCompiler "" args
-- NOTE: this won't currently work for GHCJS, because it doesn't have
-- a runghcjs binary. It probably will someday, though.
(ExecRunGhc, args) ->
```
The last line is indented by one space but it is hard to notice esp when we looking at this along with a screenful of code and there are many comments between the two lines. When this code is compiled ghc throws the following error:
```
Main.hs:745:40: error: parse error on input ‘->’
```
I look at the error and then the code and wonder what is wrong with this code, there is nothing noticeably wrong. If ghc can provide some context I can easily make out where the problem is. ghc can perhaps tell me how the current expression is being parsed e.g. `(ExecRunGhc, args) ->` is being considered as a continuation of the expression on the previous line.
I have run into this many times. The first time it was really frustrating.
<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":"Improve parse error message on indentation mistake","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":"Consider the following code fragment:\r\n{{{#!hs\r\n (ExecGhc, args) -> execCompiler \"\" args\r\n -- NOTE: this won't currently work for GHCJS, because it doesn't have\r\n -- a runghcjs binary. It probably will someday, though.\r\n (ExecRunGhc, args) ->\r\n}}}\r\n\r\nThe last line is indented by one space but it is hard to notice esp when we looking at this along with a screenful of code and there are many comments between the two lines. When this code is compiled ghc throws the following error:\r\n\r\n{{{\r\nMain.hs:745:40: error: parse error on input ‘->’\r\n}}}\r\n\r\nI look at the error and then the code and wonder what is wrong with this code, there is nothing noticeably wrong. If ghc can provide some context I can easily make out where the problem is. ghc can perhaps tell me how the current expression is being parsed e.g. `(ExecRunGhc, args) ->` is being considered as a continuation of the expression on the previous line.\r\n\r\nI have run into this many times. The first time it was really frustrating.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/106com. line args not honoured for recompil2022-09-10T21:15:58Znobodycom. line args not honoured for recompilI compiled a file with a standard compile and link and some flags, include `-fallow-overlapping-isntances`. I was interested in
whether overlapping instances were really required, so I recompiled -- without modifying the file -- without
...I compiled a file with a standard compile and link and some flags, include `-fallow-overlapping-isntances`. I was interested in
whether overlapping instances were really required, so I recompiled -- without modifying the file -- without
`-fallow-overlapping-instances`. I got the "compilation IS NOT required" message, clearly erroneous.
Suggestion: flag configuration / compiler state stored in generated code and checked on recompile.
My email is `nalexander@amavi.com`.
Thanks,
Nick6.8.1