GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:14:41Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/15014Exhaustivity check should suggest when COMPLETE could be helpful2019-07-07T18:14:41ZEdward Z. YangExhaustivity check should suggest when COMPLETE could be helpful```
MacBook-Pro-97:ghc ezyang$ cat A.hs
{-# LANGUAGE PatternSynonyms #-}
module A where
pattern F :: a -> b -> (a, b)
pattern F x y = (x, y)
g :: (a, b) -> (a, b)
g (F x y) = (x, y)
MacBook-Pro-97:ghc ezyang$ inplace/bin/ghc-stage2 -c ...```
MacBook-Pro-97:ghc ezyang$ cat A.hs
{-# LANGUAGE PatternSynonyms #-}
module A where
pattern F :: a -> b -> (a, b)
pattern F x y = (x, y)
g :: (a, b) -> (a, b)
g (F x y) = (x, y)
MacBook-Pro-97:ghc ezyang$ inplace/bin/ghc-stage2 -c A.hs -Wall -fforce-recomp
A.hs:8:1: warning: [-Wincomplete-patterns]
Pattern match(es) are non-exhaustive
In an equation for ‘g’: Patterns not matched: _
|
8 | g (F x y) = (x, y)
| ^^^^^^^^^^^^^^^^^^
MacBook-Pro-97:ghc ezyang$ inplace/bin/ghc-stage2 --version
The Glorious Glasgow Haskell Compilation System, version 8.5.20180304
```
Any time the exhaustiveness checker throws up its hands and says that `_` is not matched, we ought to give a hint that this may have occurred due to pattern synonyms, and that the author of the pattern synonyms can help out by specifying a COMPLETE pragma.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.5 |
| 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":"Exhaustivity check should suggest when COMPLETE could be helpful","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"8.4.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":["PatternMatchWarnings","PatternSynonyms,"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\nMacBook-Pro-97:ghc ezyang$ cat A.hs\r\n{-# LANGUAGE PatternSynonyms #-}\r\nmodule A where\r\n\r\npattern F :: a -> b -> (a, b)\r\npattern F x y = (x, y)\r\n\r\ng :: (a, b) -> (a, b)\r\ng (F x y) = (x, y)\r\nMacBook-Pro-97:ghc ezyang$ inplace/bin/ghc-stage2 -c A.hs -Wall -fforce-recomp\r\n\r\nA.hs:8:1: warning: [-Wincomplete-patterns]\r\n Pattern match(es) are non-exhaustive\r\n In an equation for ‘g’: Patterns not matched: _\r\n |\r\n8 | g (F x y) = (x, y)\r\n | ^^^^^^^^^^^^^^^^^^\r\nMacBook-Pro-97:ghc ezyang$ inplace/bin/ghc-stage2 --version\r\nThe Glorious Glasgow Haskell Compilation System, version 8.5.20180304\r\n}}}\r\n\r\nAny time the exhaustiveness checker throws up its hands and says that `_` is not matched, we ought to give a hint that this may have occurred due to pattern synonyms, and that the author of the pattern synonyms can help out by specifying a COMPLETE pragma.","type_of_failure":"OtherFailure","blocking":[]} -->8.4.3https://gitlab.haskell.org/ghc/ghc/-/issues/15015Parsing of exp_doc loses section markers2019-07-07T18:14:41ZLevent ErkökParsing of exp_doc loses section markersThis was originally filed as a Haddock issue, but was traced back to a parsing issue with GHC itself.
See here for details: https://github.com/haskell/haddock/issues/797
There's a work-around (by putting extra empty lines) but that's q...This was originally filed as a Haddock issue, but was traced back to a parsing issue with GHC itself.
See here for details: https://github.com/haskell/haddock/issues/797
There's a work-around (by putting extra empty lines) but that's quite fragile and would be best to fix directly in GHC.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Parser) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Parsing of exp_doc loses section markers","status":"New","operating_system":"","component":"Compiler (Parser)","related":[],"milestone":"8.4.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This was originally filed as a Haddock issue, but was traced back to a parsing issue with GHC itself.\r\n\r\nSee here for details: https://github.com/haskell/haddock/issues/797\r\n\r\nThere's a work-around (by putting extra empty lines) but that's quite fragile and would be best to fix directly in GHC.","type_of_failure":"OtherFailure","blocking":[]} -->8.4.3https://gitlab.haskell.org/ghc/ghc/-/issues/15016Referencing a do-bound variable in a rec block with ApplicativeDo results in ...2021-08-06T00:14:44ZrjmkReferencing a do-bound variable in a rec block with ApplicativeDo results in variable not in scope during type checkingI searched + hope this isn't a dupe.
When using both ApplicativeDo and RecursiveDo, referring to a do-bound variable from outside of a rec block causes a GHC internal error.
Here's a minimal example:
```hs
{-# LANGUAGE ApplicativeDo #...I searched + hope this isn't a dupe.
When using both ApplicativeDo and RecursiveDo, referring to a do-bound variable from outside of a rec block causes a GHC internal error.
Here's a minimal example:
```hs
{-# LANGUAGE ApplicativeDo #-}
{-# LANGUAGE RecursiveDo #-}
module Lib where
import Control.Monad.Fix
f :: MonadFix m => m ()
f = do
a <- return ()
rec
let b = a
return ()
```
The error message I get is
```
src/Lib.hs:12:13: error:
• GHC internal error: ‘a’ is not in scope during type checking, but it passed the renamer
tcl_env of environment: [a1pF :-> Type variable ‘m’ = m :: * -> *,
r1mX :-> Identifier[f::forall (m :: * -> *).
MonadFix m =>
m (), TopLevelLet [] True]]
• In the expression: a
In an equation for ‘b’: b = a
In a stmt of a 'do' block: rec let b = a
|
12 | let b = a
| ^
```
I have reproduced it in 8.2.2 and 8.4.1
<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":"Referencing a do-bound variable in a rec block with ApplicativeDo results in variable not in scope during type checking","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.4.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I searched + hope this isn't a dupe.\r\n\r\nWhen using both ApplicativeDo and RecursiveDo, referring to a do-bound variable from outside of a rec block causes a GHC internal error.\r\n\r\nHere's a minimal example:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE ApplicativeDo #-}\r\n{-# LANGUAGE RecursiveDo #-}\r\n\r\nmodule Lib where\r\n\r\nimport Control.Monad.Fix\r\n\r\nf :: MonadFix m => m ()\r\nf = do\r\n a <- return ()\r\n rec\r\n let b = a\r\n return ()\r\n}}}\r\n\r\nThe error message I get is\r\n\r\n\r\n{{{\r\nsrc/Lib.hs:12:13: error:\r\n • GHC internal error: ‘a’ is not in scope during type checking, but it passed the renamer\r\n tcl_env of environment: [a1pF :-> Type variable ‘m’ = m :: * -> *,\r\n r1mX :-> Identifier[f::forall (m :: * -> *).\r\n MonadFix m =>\r\n m (), TopLevelLet [] True]]\r\n • In the expression: a\r\n In an equation for ‘b’: b = a\r\n In a stmt of a 'do' block: rec let b = a\r\n |\r\n12 | let b = a\r\n | ^\r\n}}}\r\n\r\n\r\nI have reproduced it in 8.2.2 and 8.4.1\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.4.3Simon MarlowSimon Marlow