GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2020-08-12T16:14:05Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/16652Can't build `ghc-8.8` branch with `happy-1.19.10`2020-08-12T16:14:05ZRyan ScottCan't build `ghc-8.8` branch with `happy-1.19.10`Building the `ghc-8.8` branch (commit c56dad0132275841f92a02b79da7d3612ef85025) with `happy-1.19.10` results in the following error:
```
$ make -j1
===--- building phase 0
make --no-print-directory -f ghc.mk phase=0 phase_0_builds
make[...Building the `ghc-8.8` branch (commit c56dad0132275841f92a02b79da7d3612ef85025) with `happy-1.19.10` results in the following error:
```
$ make -j1
===--- building phase 0
make --no-print-directory -f ghc.mk phase=0 phase_0_builds
make[1]: Nothing to be done for 'phase_0_builds'.
===--- building phase 1
make --no-print-directory -f ghc.mk phase=1 phase_1_builds
"/opt/ghc/8.6.5/bin/ghc" -hisuf hi -osuf o -hcsuf hc -static -O0 -H64m -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -package-db libraries/bootstrapping.conf -this-unit-id ghc-8.8.0.20190426 -hide-all-packages -i -icompiler/backpack -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/hieFile -icompiler/stage1/build -Icompiler/stage1/build -icompiler/stage1/build/./autogen -Icompiler/stage1/build/./autogen -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/stage1 -Icompiler/stage1/build/. -Icompiler/stage1/build/parser -Icompiler/stage1/build/utils -Icompiler/stage1/build/stage1 -optP-include -optPcompiler/stage1/build/./autogen/cabal_macros.h -package-id array-0.5.3.0 -package-id base-4.12.0.0 -package-id binary-0.8.6.0 -package-id bytestring-0.10.8.2 -package-id containers-0.6.0.1 -package-id deepseq-1.4.4.0 -package-id directory-1.3.3.0 -package-id filepath-1.4.2.1 -package-id ghc-boot-8.8.0.20190426 -package-id ghc-boot-th-8.8.0.20190426 -package-id ghc-heap-8.8.0.20190426 -package-id ghci-8.8.0.20190426 -package-id hpc-0.6.0.3 -package-id process-1.6.5.0 -package-id template-haskell-2.15.0.0 -package-id terminfo-0.4.1.3 -package-id time-1.8.0.2 -package-id transformers-0.5.6.2 -package-id unix-2.7.2.2 -Wall -Wno-name-shadowing -Wnoncanonical-monad-instances -Wnoncanonical-monoid-instances -this-unit-id ghc -XHaskell2010 -XNoImplicitPrelude -DSTAGE=1 -Rghc-timing -O -Wcpp-undef -no-user-package-db -rtsopts -O0 -fno-ignore-interface-pragmas -fcmm-sink -outputdir compiler/stage1/build -c compiler/stage1/build/Parser.hs -o compiler/stage1/build/Parser.o
compiler/stage1/build/Parser.hs:1487:48: error:
Not in scope: type variable ‘a’
|
1487 | newtype HappyWrap211 = HappyWrap211 (([Located a],Bool))
| ^
<<ghc: 1566236888 bytes, 272 GCs, 22676065/72601344 avg/max bytes residency (8 samples), 152M in use, 0.000 INIT (0.000 elapsed), 0.549 MUT (0.560 elapsed), 0.464 GC (0.464 elapsed) :ghc>>
compiler/ghc.mk:444: recipe for target 'compiler/stage1/build/Parser.o' failed
make[1]: *** [compiler/stage1/build/Parser.o] Error 1
Makefile:123: recipe for target 'all' failed
make: *** [all] Error 2
```
The use of `make` here is inconsequential, as the same error also occurs with Hadrian.
cc @int\-index8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/16339Cannot put (.) or (!) type operators into an export list2019-07-07T18:00:27ZRyan ScottCannot put (.) or (!) type operators into an export listThanks to recent work in GHC HEAD, it is now possible to define type operators named `(.)` and `(!)`:
```hs
type (f . g) x = f (g x)
type x ! f = f x
```
However, I was surprised to discover that it's not possible to put them in an exp...Thanks to recent work in GHC HEAD, it is now possible to define type operators named `(.)` and `(!)`:
```hs
type (f . g) x = f (g x)
type x ! f = f x
```
However, I was surprised to discover that it's not possible to put them in an export list! That is to say, this program doesn't parse:
```
{-# LANGUAGE TypeOperators #-}
module Bug (type (.), type (!)) where
type (f . g) x = f (g x)
type x ! f = f x
```
```
$ ~/Software/ghc4/inplace/bin/ghc-stage2 --interactive Bug.hs
GHCi, version 8.7.20190219: https://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
Bug.hs:2:19: error: parse error on input ‘.’
|
2 | module Bug (type (.), type (!)) where
| ^
```
This problem appears to be specific to the `(.)` and `(!)` type operators, since any other type operator will work in its place:
```hs
{-# LANGUAGE TypeOperators #-}
module Works (type (&)) where
type (f & g) x = f (g x)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 8.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Parser) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | int-index |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Cannot put (.) or (!) into an export list","status":"New","operating_system":"","component":"Compiler (Parser)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["int-index"],"type":"Bug","description":"Thanks to recent work in GHC HEAD, it is now possible to define type operators named `(.)` and `(!)`:\r\n\r\n{{{#!hs\r\ntype (f . g) x = f (g x)\r\ntype x ! f = f x\r\n}}}\r\n\r\nHowever, I was surprised to discover that it's not possible to put them in an export list! That is to say, this program doesn't parse:\r\n\r\n{{{\r\n{-# LANGUAGE TypeOperators #-}\r\nmodule Bug (type (.), type (!)) where\r\n\r\ntype (f . g) x = f (g x)\r\ntype x ! f = f x\r\n}}}\r\n{{{\r\n$ ~/Software/ghc4/inplace/bin/ghc-stage2 --interactive Bug.hs\r\nGHCi, version 8.7.20190219: https://www.haskell.org/ghc/ :? for help\r\nLoaded GHCi configuration from /home/rgscott/.ghci\r\n\r\nBug.hs:2:19: error: parse error on input ‘.’\r\n |\r\n2 | module Bug (type (.), type (!)) where\r\n | ^\r\n}}}\r\n\r\nThis problem appears to be specific to the `(.)` and `(!)` type operators, since any other type operator will work in its place:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE TypeOperators #-}\r\nmodule Works (type (&)) where\r\n\r\ntype (f & g) x = f (g x)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/16311Suggest -XExistentialQuantification for 'forall' in data declarations2019-07-07T18:00:34ZVladislav ZavialovSuggest -XExistentialQuantification for 'forall' in data declarations[D5180](https://phabricator.haskell.org/D5180) introduced a slight regression to the error messages. In this code
```hs
data T = forall a. MkT a
```
GHC used to complain
```
rnfail053.hs:5:10:
Not a data constructor: ‘forall’
...[D5180](https://phabricator.haskell.org/D5180) introduced a slight regression to the error messages. In this code
```hs
data T = forall a. MkT a
```
GHC used to complain
```
rnfail053.hs:5:10:
Not a data constructor: ‘forall’
Perhaps you intended to use ExistentialQuantification
```
but then the message has become
```
rnfail053.hs:5:18: error:
Illegal symbol '.' in type
Perhaps you intended to use RankNTypes or a similar language
extension to enable explicit-forall syntax: forall <tvs>. <type>
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 8.6.3 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Parser) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Suggest -XExistentialQuantification for 'forall' in data declarations","status":"New","operating_system":"","component":"Compiler (Parser)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"Phab:D5180 introduced a slight regression to the error messages. In this code\r\n\r\n{{{#!hs\r\ndata T = forall a. MkT a\r\n}}}\r\n\r\nGHC used to complain\r\n\r\n{{{\r\nrnfail053.hs:5:10:\r\n Not a data constructor: ‘forall’\r\n Perhaps you intended to use ExistentialQuantification\r\n}}}\r\n\r\nbut then the message has become\r\n\r\n{{{\r\nrnfail053.hs:5:18: error:\r\n Illegal symbol '.' in type\r\n Perhaps you intended to use RankNTypes or a similar language\r\n extension to enable explicit-forall syntax: forall <tvs>. <type>\r\n}}}\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/17797Lexer errors for newer unicode characters2020-02-06T23:54:14ZdminuosoLexer errors for newer unicode charactersIt appears that character from Unicode 6.0 and above lead to lexer errors.
```
unicode.hs:1:2: error: lexical error at character '\129315'
|
1 | (🤣) = ()
| ^
```It appears that character from Unicode 6.0 and above lead to lexer errors.
```
unicode.hs:1:2: error: lexical error at character '\129315'
|
1 | (🤣) = ()
| ^
```8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/16279Lexer: Alternate Layout Rule injects actual not virtual braces2019-07-07T18:00:42ZAlan ZimmermanLexer: Alternate Layout Rule injects actual not virtual bracesWhen the alternate layout rule is activated via a pragma, it injects tokens for `{` and `}` to make sure that the source is parsed properly.
But it injects `ITocurly` and `ITccurly`, rather than their virtual counterparts `ITvocurly` an...When the alternate layout rule is activated via a pragma, it injects tokens for `{` and `}` to make sure that the source is parsed properly.
But it injects `ITocurly` and `ITccurly`, rather than their virtual counterparts `ITvocurly` and `ITvccurly`.
This causes problems for `ghc-exactprint`, which tries to print these.
Test case (the existing T13087.hs)
```hs
{-# LANGUAGE AlternativeLayoutRule #-}
{-# LANGUAGE LambdaCase #-}
isOne :: Int -> Bool
isOne = \case 1 -> True
_ -> False
main = return ()
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 8.6.3 |
| 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":"Lexer: Alternate Layout Rule injects actual not virtual braces","status":"New","operating_system":"","component":"Compiler (Parser)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When the alternate layout rule is activated via a pragma, it injects tokens for `{` and `}` to make sure that the source is parsed properly.\r\n\r\nBut it injects `ITocurly` and `ITccurly`, rather than their virtual counterparts `ITvocurly` and `ITvccurly`.\r\n\r\nThis causes problems for `ghc-exactprint`, which tries to print these.\r\n\r\nTest case (the existing T13087.hs)\r\n \r\n{{{#!hs\r\n{-# LANGUAGE AlternativeLayoutRule #-}\r\n{-# LANGUAGE LambdaCase #-}\r\n\r\nisOne :: Int -> Bool\r\nisOne = \\case 1 -> True\r\n _ -> False\r\n\r\nmain = return ()\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Alan ZimmermanAlan Zimmermanhttps://gitlab.haskell.org/ghc/ghc/-/issues/16265API Annotations: parens anns discarded for `(*)` operator2019-07-07T18:00:45ZAlan ZimmermanAPI Annotations: parens anns discarded for `(*)` operatorThe patch from https://phabricator.haskell.org/D4865 introduces
```hs
go _ (HsParTy _ (dL->L l (HsStarTy _ isUni))) acc ann fix
= do { warnStarBndr l
; let name = mkOccName tcClsName (if isUni then "★" else "*")
...The patch from https://phabricator.haskell.org/D4865 introduces
```hs
go _ (HsParTy _ (dL->L l (HsStarTy _ isUni))) acc ann fix
= do { warnStarBndr l
; let name = mkOccName tcClsName (if isUni then "★" else "*")
; return (cL l (Unqual name), acc, fix, ann) }
```
which discards the parens annotations belonging to the `HsParTy`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 8.6.3 |
| 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":"API Annotations: parens anns discarded for `(*)` operator","status":"New","operating_system":"","component":"Compiler (Parser)","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The patch from https://phabricator.haskell.org/D4865 introduces\r\n\r\n{{{#!hs\r\n go _ (HsParTy _ (dL->L l (HsStarTy _ isUni))) acc ann fix\r\n = do { warnStarBndr l\r\n ; let name = mkOccName tcClsName (if isUni then \"★\" else \"*\")\r\n ; return (cL l (Unqual name), acc, fix, ann) }\r\n}}}\r\n\r\nwhich discards the parens annotations belonging to the `HsParTy`.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Alan ZimmermanAlan Zimmermanhttps://gitlab.haskell.org/ghc/ghc/-/issues/16236API Annotations: AnnAt disconnected for TYPEAPP2019-07-07T18:00:51ZAlan ZimmermanAPI Annotations: AnnAt disconnected for TYPEAPPFor the code
```hs
type family F1 (a :: k) (f :: k -> Type) :: Type where
F1 @Peano a f = T @Peano f a
```
the API annotation for the first `@` is not attached to a `SourcSpan` in the `ParsedSource`
<details><summary>Trac metadata</...For the code
```hs
type family F1 (a :: k) (f :: k -> Type) :: Type where
F1 @Peano a f = T @Peano f a
```
the API annotation for the first `@` is not attached to a `SourcSpan` in the `ParsedSource`
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 8.6.3 |
| 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":"API Annotations: AnnAt disconnected for TYPEAPP","status":"New","operating_system":"","component":"Compiler (Parser)","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"For the code\r\n\r\n{{{#!hs\r\ntype family F1 (a :: k) (f :: k -> Type) :: Type where\r\n F1 @Peano a f = T @Peano f a\r\n}}}\r\n\r\nthe API annotation for the first `@` is not attached to a `SourcSpan` in the `ParsedSource`","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Alan ZimmermanAlan Zimmermanhttps://gitlab.haskell.org/ghc/ghc/-/issues/16230API Annotations: more explicit foralls fixup2019-07-07T18:00:53ZAlan ZimmermanAPI Annotations: more explicit foralls fixupThe `AnnForall` annotations introduced via [D4894](https://phabricator.haskell.org/D4894) are not always attached to the correct `SourceSpan`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| -...The `AnnForall` annotations introduced via [D4894](https://phabricator.haskell.org/D4894) are not always attached to the correct `SourceSpan`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 8.6.3 |
| 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":"API Annotations: more explicit foralls fixup","status":"New","operating_system":"","component":"Compiler (Parser)","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The `AnnForall` annotations introduced via Phab:D4894 are not always attached to the correct `SourceSpan`.\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Alan ZimmermanAlan Zimmermanhttps://gitlab.haskell.org/ghc/ghc/-/issues/16212API Annotations: Parens not attached correctly for ClassDecl2019-07-07T18:00:57ZAlan ZimmermanAPI Annotations: Parens not attached correctly for ClassDeclFor the file
```hs
module ClassParens where
class LiftingMonad (trans :: MTrans) where
proof :: Monad m :- Monad (trans m)
class LiftingMonad2 ((trans :: MTrans)) where
proof :: Monad m :- Monad (trans m)
```
The parens around ...For the file
```hs
module ClassParens where
class LiftingMonad (trans :: MTrans) where
proof :: Monad m :- Monad (trans m)
class LiftingMonad2 ((trans :: MTrans)) where
proof :: Monad m :- Monad (trans m)
```
The parens around the kinded tyvars should be attached to the class declaration as a whole, they are attached to the tyvar instead, outside the span.
An annotation must always be within the span it is contained in.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 8.6.3 |
| 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":"API Annotations: Parens not attached correctly for ClassDecl","status":"New","operating_system":"","component":"Compiler (Parser)","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"For the file\r\n\r\n{{{#!hs\r\nmodule ClassParens where\r\n\r\nclass LiftingMonad (trans :: MTrans) where\r\n proof :: Monad m :- Monad (trans m)\r\n\r\nclass LiftingMonad2 ((trans :: MTrans)) where\r\n proof :: Monad m :- Monad (trans m)\r\n}}}\r\n\r\nThe parens around the kinded tyvars should be attached to the class declaration as a whole, they are attached to the tyvar instead, outside the span. \r\n\r\nAn annotation must always be within the span it is contained in.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Alan ZimmermanAlan Zimmermanhttps://gitlab.haskell.org/ghc/ghc/-/issues/15781Extraneous parentheses required to parse kind signature on the RHS of a type ...2019-07-07T18:03:02ZRyan ScottExtraneous parentheses required to parse kind signature on the RHS of a type synonymAfter [D5173](https://phabricator.haskell.org/D5173), the restrictions about where kind signatures can appear in the source were significantly relaxed so that things like:
```hs
type family F where
F = Int :: Type
```
Are now allowed...After [D5173](https://phabricator.haskell.org/D5173), the restrictions about where kind signatures can appear in the source were significantly relaxed so that things like:
```hs
type family F where
F = Int :: Type
```
Are now allowed. However, there appears to be one case that was missed in that patch: the right-hand sides of type synonyms. For instance, I would expect the following to parse:
```hs
{-# LANGUAGE KindSignatures #-}
module Bug where
import Data.Kind
type F = Int :: Type
```
However, even GHC HEAD still refuses to parse this:
```
$ /opt/ghc/head/bin/ghci Bug.hs
GHCi, version 8.7.20181015: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
[1 of 1] Compiling Bug ( Bug.hs, interpreted )
Bug.hs:6:14: error: parse error on input ‘::’
|
6 | type F = Int :: Type
| ^^
```
Luckily, I don't think this will be too difficult to fix, since all that needs to be done is to update the parser production for type synonyms to use something like `ktype` instead of `ctype`. Patch incoming.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 8.7 |
| 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":"Extraneous parentheses required to parse kind signature on the RHS of a type synonym","status":"New","operating_system":"","component":"Compiler (Parser)","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"After Phab:D5173, the restrictions about where kind signatures can appear in the source were significantly relaxed so that things like:\r\n\r\n{{{#!hs\r\ntype family F where\r\n F = Int :: Type\r\n}}}\r\n\r\nAre now allowed. However, there appears to be one case that was missed in that patch: the right-hand sides of type synonyms. For instance, I would expect the following to parse:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE KindSignatures #-}\r\nmodule Bug where\r\n\r\nimport Data.Kind\r\n\r\ntype F = Int :: Type\r\n}}}\r\n\r\nHowever, even GHC HEAD still refuses to parse this:\r\n\r\n{{{\r\n$ /opt/ghc/head/bin/ghci Bug.hs\r\nGHCi, version 8.7.20181015: http://www.haskell.org/ghc/ :? for help\r\nLoaded GHCi configuration from /home/rgscott/.ghci\r\n[1 of 1] Compiling Bug ( Bug.hs, interpreted )\r\n\r\nBug.hs:6:14: error: parse error on input ‘::’\r\n |\r\n6 | type F = Int :: Type\r\n | ^^\r\n}}}\r\n\r\nLuckily, I don't think this will be too difficult to fix, since all that needs to be done is to update the parser production for type synonyms to use something like `ktype` instead of `ctype`. Patch incoming.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15675Type operators in existential context cannot be parsed2019-07-07T18:03:29ZVladislav ZavialovType operators in existential context cannot be parsed```haskell
{-# LANGUAGE TypeOperators, MultiParamTypeClasses, ExistentialQuantification #-}
class a + b
data D1 = forall a b. (a + b) => D1 a b
data D2 = forall a b. a + b => D2 a b
```
The declaration `D1` is accepted, while `D2` i...```haskell
{-# LANGUAGE TypeOperators, MultiParamTypeClasses, ExistentialQuantification #-}
class a + b
data D1 = forall a b. (a + b) => D1 a b
data D2 = forall a b. a + b => D2 a b
```
The declaration `D1` is accepted, while `D2` is rejected. There is no reason to reject `D2` except for shortcomings of the current grammar.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 8.4.3 |
| 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":"Type operators in existential context cannot be parsed","status":"New","operating_system":"","component":"Compiler (Parser)","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{#!haskell\r\n{-# LANGUAGE TypeOperators, MultiParamTypeClasses, ExistentialQuantification #-}\r\n\r\nclass a + b\r\n\r\ndata D1 = forall a b. (a + b) => D1 a b\r\ndata D2 = forall a b. a + b => D2 a b\r\n}}}\r\n\r\nThe declaration `D1` is accepted, while `D2` is rejected. There is no reason to reject `D2` except for shortcomings of the current grammar.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Vladislav ZavialovVladislav Zavialovhttps://gitlab.haskell.org/ghc/ghc/-/issues/15457(~) and (!) are parsed inconsistently in types (plus documentation warts)2019-07-07T18:04:48ZRyan Scott(~) and (!) are parsed inconsistently in types (plus documentation warts)(Spawned from #10056?replyto=41\##15457)
`~` and `!` are slightly special in the parser to allow strict annotations and lazy annotations (with `-XStrict`) in data types. As a result, we initially parse all uses of `~`/`!` as bangs, and ...(Spawned from #10056?replyto=41\##15457)
`~` and `!` are slightly special in the parser to allow strict annotations and lazy annotations (with `-XStrict`) in data types. As a result, we initially parse all uses of `~`/`!` as bangs, and we use a post-parsing pass (`mergeOps`/`splitTilde`) to figure out which uses of `~` are actually meant to refer to the equality type constructor.
There's a couple of unsatisfying things here:
1. `splitTilde` handles `~`, but not `!`. This means that any use of `!` as a type operator will not work, as evidenced by this GHCi session:
```
λ> type a ! b = Either a b
<interactive>:1:6: error:
Malformed head of type or class declaration: a !b
```
> We should update `splitTilde` to handle `!` as well. (And perhaps give that function a new name to reflect its more ambitious goals.)
1. `Note [Parsing ~]` is supposed to explain all of this hullabaloo, but it does a rather poor job of it. Let's add some more prose to it.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 8.4.3 |
| 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":"(~) and (!) are parsed inconsistently in types (plus documentation warts)","status":"New","operating_system":"","component":"Compiler (Parser)","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"(Spawned from https://ghc.haskell.org/trac/ghc/ticket/10056?replyto=41#comment:41)\r\n\r\n`~` and `!` are slightly special in the parser to allow strict annotations and lazy annotations (with `-XStrict`) in data types. As a result, we initially parse all uses of `~`/`!` as bangs, and we use a post-parsing pass (`mergeOps`/`splitTilde`) to figure out which uses of `~` are actually meant to refer to the equality type constructor.\r\n\r\nThere's a couple of unsatisfying things here:\r\n\r\n1. `splitTilde` handles `~`, but not `!`. This means that any use of `!` as a type operator will not work, as evidenced by this GHCi session:\r\n\r\n{{{\r\nλ> type a ! b = Either a b\r\n\r\n<interactive>:1:6: error:\r\n Malformed head of type or class declaration: a !b\r\n}}}\r\n\r\n We should update `splitTilde` to handle `!` as well. (And perhaps give that function a new name to reflect its more ambitious goals.)\r\n2. `Note [Parsing ~]` is supposed to explain all of this hullabaloo, but it does a rather poor job of it. Let's add some more prose to it.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Vladislav ZavialovVladislav Zavialovhttps://gitlab.haskell.org/ghc/ghc/-/issues/13087AlternativeLayoutRule breaks LambdaCase2019-07-07T18:23:46ZohhellojoeAlternativeLayoutRule breaks LambdaCase```hs
{-# LANGUAGE AlternativeLayoutRule #-}
{-# LANGUAGE LambdaCase #-}
isOne :: Int -> Bool
isOne = \case 1 -> True
_ -> False
main = return ()
```
```
$ ghc test-case
[1 of 1] Compiling Main ( t...```hs
{-# LANGUAGE AlternativeLayoutRule #-}
{-# LANGUAGE LambdaCase #-}
isOne :: Int -> Bool
isOne = \case 1 -> True
_ -> False
main = return ()
```
```
$ ghc test-case
[1 of 1] Compiling Main ( test-case.hs, test-case.o )
test-case.hs:5:15: error: parse error on input ‘1’
```
It compiles fine without the AlternativeLayoutRule extension.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 8.0.1 |
| 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":"AlternativeLayoutRule breaks LambdaCase","status":"New","operating_system":"","component":"Compiler (Parser)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{#!hs\r\n{-# LANGUAGE AlternativeLayoutRule #-}\r\n{-# LANGUAGE LambdaCase #-}\r\n\r\nisOne :: Int -> Bool\r\nisOne = \\case 1 -> True\r\n _ -> False\r\n\r\nmain = return ()\r\n}}}\r\n\r\n{{{\r\n$ ghc test-case\r\n[1 of 1] Compiling Main ( test-case.hs, test-case.o )\r\n\r\ntest-case.hs:5:15: error: parse error on input ‘1’\r\n}}}\r\n\r\nIt compiles fine without the AlternativeLayoutRule extension.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/8708Kind annotation in tuple not parsed2021-12-20T19:28:41ZRichard Eisenbergrae@richarde.devKind annotation in tuple not parsedConsider this:
```
{-# LANGUAGE KindSignatures #-}
foo :: (Int, Int :: *)
foo = undefined
```
HEAD reports
```
/Users/rae/temp/Bug.hs:5:18: parse error on input ‛::’
```
Changing the line to
```
foo :: (Int, (Int :: *))
```
fixes ...Consider this:
```
{-# LANGUAGE KindSignatures #-}
foo :: (Int, Int :: *)
foo = undefined
```
HEAD reports
```
/Users/rae/temp/Bug.hs:5:18: parse error on input ‛::’
```
Changing the line to
```
foo :: (Int, (Int :: *))
```
fixes the problem. Note the extra parentheses.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 7.7 |
| 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":"Kind annotation in tuple not parsed","status":"New","operating_system":"","component":"Compiler (Parser)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Consider this:\r\n\r\n{{{\r\n{-# LANGUAGE KindSignatures #-}\r\n\r\nfoo :: (Int, Int :: *)\r\nfoo = undefined\r\n}}}\r\n\r\nHEAD reports\r\n\r\n{{{\r\n/Users/rae/temp/Bug.hs:5:18: parse error on input ‛::’\r\n}}}\r\n\r\nChanging the line to\r\n\r\n{{{\r\nfoo :: (Int, (Int :: *))\r\n}}}\r\n\r\nfixes the problem. Note the extra parentheses.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/314#line pragmas not respected inside nested comments2019-07-07T19:18:30Znobody#line pragmas not respected inside nested comments```
If one tries to compile a .hs file, with the -cpp
option and the file contains
C-style comments (/* comment */), then the linenumbers
GHC reports
are wrong.
Minimal file exhibiting the error:
---
{-
/*
* Copyright (c) 2005 Jesper...```
If one tries to compile a .hs file, with the -cpp
option and the file contains
C-style comments (/* comment */), then the linenumbers
GHC reports
are wrong.
Minimal file exhibiting the error:
---
{-
/*
* Copyright (c) 2005 Jesper Louis Andersen
<jlouis@mongers.org>
*
* Permission to use, copy, modify, and distribute this
software for any
* purpose with or without fee is hereby granted,
provided that the above
* copyright notice and this permission notice appear
in all copies.
*
* THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR
DISCLAIMS ALL WARRANTIES
* WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED
WARRANTIES OF
* MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE
AUTHOR BE LIABLE FOR
* ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
DAMAGES OR ANY DAMAGES
* WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
PROFITS, WHETHER IN AN
* ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
ACTION, ARISING OUT OF
* OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
SOFTWARE.
*/
-}
c = 3 * "string"
main = putStrLn $ show c
----
; ghc -cpp tmp.hs
tmp.hs:6:
No instance for (Num [Char])
arising from use of `*' at tmp.hs:6
In the definition of `c': c = 3 * "string"
Which is clearly wrong, since ``c'' is not defined on
line 6.
Note I am not sure wether it is in the parser, or it is
rather in compilation
chain where cpp gets invoked one has to look for the
error. I have filed
it as a parser-bug nonetheless.
Fix: cpp(1) seems to output comments in the style
# xx "filename"
where ``xx'' is a number stating the linenumber in the
original file.
Keeping track of this probably fixes the bug.
CPP version: GNU CPP from GCC 3.3.5
Operating System: OpenBSD 3.6-current (GENERIC) #1: Sun
Feb 20 10:23:54 CET 2005
Submitter: Jesper Louis Andersen <jlouis@mongers.org>
```8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/16654Parser performance regression after disabling happy's --coerce option2020-08-12T16:14:55ZDavid EichmannParser performance regression after disabling happy's --coerce optionAccording to @int\-index via GHC-devs (https://mail.haskell.org/pipermail/ghc-devs/2019-May/017600.html):
> This February I did some changes to the parser that require higher rank types support in ‘happy’. Unfortunately, as I discover...According to @int\-index via GHC-devs (https://mail.haskell.org/pipermail/ghc-devs/2019-May/017600.html):
> This February I did some changes to the parser that require higher rank types support in ‘happy’. Unfortunately, as I discovered, happy’s --coerce option is severely broken in the presence of higher rank types, so I had to disable it. My benchmarks have shown a 10% slowdown from disabling --coerce (https://gist.github.com/int-index/38af0c5dd801088dc1de59eca4e55df4).
>
> Alongside my changes I submitted a pull request to happy which fixes the issue (https://github.com/simonmar/happy/pull/134), in the hope that it would get merged, released, and I could re-enable --coerce in GHC ‘happy' configuration.
1. [X] Merge https://github.com/simonmar/happy/pull/134
2. [x] Release a new ‘happy’
3. [x] (Optional) Specify in GHC’s build system that it builds only with the latest 'happy' release
4. [x] Restore the --coerce option in GHC’s build system ‘happy’ configuration
5. [ ] Backport it to the ghc-8.8 branch
We also need to:
6. [x] Update CI docker images8.8.1David EichmannDavid Eichmann