GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2023-11-28T14:49:42Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/19623EPA: encode keywords directly in AST2023-11-28T14:49:42ZVladislav ZavialovEPA: encode keywords directly in ASTI voiced my concerns about the design of in-tree exactprint annotations here: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/2418#note_338403. The result of the discussion was that we’d go with my proposed design, but implement it p...I voiced my concerns about the design of in-tree exactprint annotations here: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/2418#note_338403. The result of the discussion was that we’d go with my proposed design, but implement it post-merge. This ticket is to track the proposed refactoring.
The new design is described as “Plan B” at https://gitlab.haskell.org/ghc/ghc/-/wikis/api-annotations. The idea is to introduce a new data type, `HsToken`, defined as follows:
```
type LHsToken tok p = XRec p (HsToken tok)
data HsToken (tok :: Symbol) = HsTok
```
Then we record token information directly in the syntax tree:
```diff
data HsExpr p
= ...
...
| HsLet (XLet p)
+ !(LHsToken "let")
(LHsLocalBinds p)
+ !(LHsToken "in")
(LHsExpr p)
```
----
While working on this, I found the following commands useful:
```
hadrian/build -j --flavour=Quick --freeze1 test --test-root-dirs=testsuite/tests/printer
hadrian/build -j --flavour=Quick --freeze1 test --test-root-dirs=testsuite/tests/ghc-api/exactprint
```Vladislav ZavialovAlan ZimmermanVladislav Zavialovhttps://gitlab.haskell.org/ghc/ghc/-/issues/22771EPA: HsOverLabel does not capture quotes around strings2023-02-01T13:31:37ZAlan ZimmermanEPA: HsOverLabel does not capture quotes around stringsAn overloaded label of the form `#"3"` stores the label `3` without quotes.
This means we cannot exact print it.An overloaded label of the form `#"3"` stores the label `3` without quotes.
This means we cannot exact print it.9.6.1Alan ZimmermanAlan Zimmermanhttps://gitlab.haskell.org/ghc/ghc/-/issues/22410ghc-9.4.3 fails to compile ghc-exactprint-1.6.02022-11-08T23:00:40ZCheng Shaoghc-9.4.3 fails to compile ghc-exactprint-1.6.0## Summary
`ghc-9.4.3` fails to compile `ghc-exactprint-1.6.0`, but it used to work in `ghc-9.4.2`.
## Steps to reproduce
```
ghcup install ghc 9.4.3 -u "https://downloads.haskell.org/ghc/9.4.3/ghc-9.4.3-x86_64-fedora33-linux.tar.xz"
...## Summary
`ghc-9.4.3` fails to compile `ghc-exactprint-1.6.0`, but it used to work in `ghc-9.4.2`.
## Steps to reproduce
```
ghcup install ghc 9.4.3 -u "https://downloads.haskell.org/ghc/9.4.3/ghc-9.4.3-x86_64-fedora33-linux.tar.xz"
cabal --with-compiler=ghc-9.4.3 install ghc-exactprint-1.6.0
```
## Expected behavior
Should compile it to completion.
## Actual behavior
```
src/Language/Haskell/GHC/ExactPrint/ExactPrint.hs:3228:12: error:
* Could not deduce (ExactPrint (GenLocated SrcSpanAnnN FastString))
arising from a use of `markAnnotated'
from the context: (Monad m, Monoid w)
bound by the type signature for:
exact :: forall (m :: * -> *) w.
(Monad m, Monoid w) =>
DotFieldOcc GhcPs -> EP w m (DotFieldOcc GhcPs)
at src/Language/Haskell/GHC/ExactPrint/ExactPrint.hs:3226:3-7
* In a stmt of a 'do' block: fs' <- markAnnotated fs
In the expression:
do an0 <- markLensKwM an lafDot AnnDot
fs' <- markAnnotated fs
return (DotFieldOcc an0 fs')
In an equation for `exact':
exact (DotFieldOcc an fs)
= do an0 <- markLensKwM an lafDot AnnDot
fs' <- markAnnotated fs
return (DotFieldOcc an0 fs')
|
3228 | fs' <- markAnnotated fs
| ^^^^^^^^^^^^^
```
## Environment
* GHC version used: 9.4.3
Optional:
* Operating System: Ubuntu 22.04
* System Architecture: x86_64Alan ZimmermanAlan Zimmermanhttps://gitlab.haskell.org/ghc/ghc/-/issues/23892EPA: Incorrect span for LWarnDec GhcPs2023-09-18T21:47:33ZAlan ZimmermanEPA: Incorrect span for LWarnDec GhcPsThe code (from T23465.hs)
```hs
{-# WARNInG in "x-c" e "d" #-}
e = e
```
gives an incorrect span for the `LWarnDecl GhcPs`The code (from T23465.hs)
```hs
{-# WARNInG in "x-c" e "d" #-}
e = e
```
gives an incorrect span for the `LWarnDecl GhcPs`9.8.1Alan ZimmermanAlan Zimmermanhttps://gitlab.haskell.org/ghc/ghc/-/issues/23887EPA: Incorrect locations for UserTyVar with '@'2023-09-15T03:26:26ZAlan ZimmermanEPA: Incorrect locations for UserTyVar with '@'In T13343.hs, the location for the `@` is not within the span of the surrounding `UserTyVar`.
```hs
type Bad @v = (forall (v1 :: RuntimeRep) (a1 :: TYPE v). a1) :: TYPE v
```In T13343.hs, the location for the `@` is not within the span of the surrounding `UserTyVar`.
```hs
type Bad @v = (forall (v1 :: RuntimeRep) (a1 :: TYPE v). a1) :: TYPE v
```9.8.1Alan ZimmermanAlan Zimmermanhttps://gitlab.haskell.org/ghc/ghc/-/issues/23885EPA: unrestrictedFunTyCon in RdrName does not capture unicode variant2023-09-18T19:01:18ZAlan ZimmermanEPA: unrestrictedFunTyCon in RdrName does not capture unicode variantThe uses of `'->'` in Parser.y that capture a `LocatedN RdrName` does account for the unicode variant of the token.The uses of `'->'` in Parser.y that capture a `LocatedN RdrName` does account for the unicode variant of the token.9.8.1Alan ZimmermanAlan Zimmermanhttps://gitlab.haskell.org/ghc/ghc/-/issues/23459EPA: remove duplicated comments when using '-haddock'2023-10-31T11:42:29ZAlan ZimmermanEPA: remove duplicated comments when using '-haddock'When the `-haddock` GHC flag is set, the haddock comments are interspersed into the AST.
But they also appear with the "normal" comments.
At the moment exact printing ignores the ones interspersed in the tree (actually panics when they a...When the `-haddock` GHC flag is set, the haddock comments are interspersed into the AST.
But they also appear with the "normal" comments.
At the moment exact printing ignores the ones interspersed in the tree (actually panics when they are hit),
and (badly) prints the structured comments.
Adjust the lexer to not emit the haddock EPA comments when the flag is set, and use the ones in the AST for exact printing.Alan ZimmermanAlan Zimmermanhttps://gitlab.haskell.org/ghc/ghc/-/issues/22919EPA: Comment between module and where should be in header comments2023-06-06T07:15:42ZAlan ZimmermanEPA: Comment between module and where should be in header commentsFor the source
```hs
module ModuleWhere {- comment -} where
foo = 's'
```
The comment should be in the `HsModule` header comments.
Instead it is attached to `foo = 's'`.
It attached correctly if we put a blank line before `foo = 's'`.For the source
```hs
module ModuleWhere {- comment -} where
foo = 's'
```
The comment should be in the `HsModule` header comments.
Instead it is attached to `foo = 's'`.
It attached correctly if we put a blank line before `foo = 's'`.9.6.1Alan ZimmermanAlan Zimmermanhttps://gitlab.haskell.org/ghc/ghc/-/issues/22765EPA: no annotation for 'type' in Parser.y 'type_data_or_newtype' rule2023-02-01T11:08:21ZAlan ZimmermanEPA: no annotation for 'type' in Parser.y 'type_data_or_newtype' rule
The rule
```
type_data_or_newtype :: { Located (AddEpAnn, Bool, NewOrData) }
: 'data' { sL1 $1 (mj AnnData $1,False,DataType) }
| 'newtype' { sL1 $1 (mj AnnNewtype $1,False,NewType) }
| 'type' 'dat...
The rule
```
type_data_or_newtype :: { Located (AddEpAnn, Bool, NewOrData) }
: 'data' { sL1 $1 (mj AnnData $1,False,DataType) }
| 'newtype' { sL1 $1 (mj AnnNewtype $1,False,NewType) }
| 'type' 'data' { sL1 $1 (mj AnnData $1,True ,DataType) }
```
does not return a `AnnType` annotation in the third production.9.6.1Alan ZimmermanAlan Zimmermanhttps://gitlab.haskell.org/ghc/ghc/-/issues/21805EPA: DotFieldOcc does not have exact print annotations2022-11-01T21:47:02ZAlan ZimmermanEPA: DotFieldOcc does not have exact print annotationsFor the code
```hs
{-# LANGUAGE OverloadedRecordUpdate #-}
operatorUpdate f = f{(+) = 1}
```
There are no exact print annotations for the parens around the `+` symbolFor the code
```hs
{-# LANGUAGE OverloadedRecordUpdate #-}
operatorUpdate f = f{(+) = 1}
```
There are no exact print annotations for the parens around the `+` symbol9.4.3Alan ZimmermanAlan Zimmermanhttps://gitlab.haskell.org/ghc/ghc/-/issues/21005EPA: AnnList field al_anchor is unused2022-01-31T23:10:45ZAlan ZimmermanEPA: AnnList field al_anchor is unusedThe data type `AnnList` has a field `al_anchor`.
This is not used for exact printing, and should be removed.The data type `AnnList` has a field `al_anchor`.
This is not used for exact printing, and should be removed.9.4.1Alan ZimmermanAlan Zimmermanhttps://gitlab.haskell.org/ghc/ghc/-/issues/20951EPA: Explicitly capture the EOF position in AnnsModule2022-12-23T08:39:13ZAlan ZimmermanEPA: Explicitly capture the EOF position in AnnsModuleAt the moment the EOF position is encoded in a pseudo-comment as `EpaEofComment`.
This makes it difficult to place after ExactPrint delta processing, where the `Anchor` has a `MovedAnchor` operation and items have been added to the AST....At the moment the EOF position is encoded in a pseudo-comment as `EpaEofComment`.
This makes it difficult to place after ExactPrint delta processing, where the `Anchor` has a `MovedAnchor` operation and items have been added to the AST.
Rather record it explicitly in `AnnsModule` as an anchor, which can be exact printed last.9.2.2Alan ZimmermanAlan Zimmermanhttps://gitlab.haskell.org/ghc/ghc/-/issues/20950EPA: LGRHS should have an Anchor2022-11-08T22:12:25ZAlan ZimmermanEPA: LGRHS should have an AnchorAt the moment the `Anno` instance for `GRHS` resolves to `SrcSpan`.
It should resolve to something with an `Anchor` in itAt the moment the `Anno` instance for `GRHS` resolves to `SrcSpan`.
It should resolve to something with an `Anchor` in it9.2.2Alan ZimmermanAlan Zimmermanhttps://gitlab.haskell.org/ghc/ghc/-/issues/20718EPA: comment order reversed2022-05-30T17:12:27ZAlan ZimmermanEPA: comment order reversedThe code
```hs
module CommentOrder where
x = 1
-- First
-- Second
-- Third
```
results in the three comments appearing in reverse order in the `HsModule` Exact Print Annotation.The code
```hs
module CommentOrder where
x = 1
-- First
-- Second
-- Third
```
results in the three comments appearing in reverse order in the `HsModule` Exact Print Annotation.Alan ZimmermanAlan Zimmermanhttps://gitlab.haskell.org/ghc/ghc/-/issues/20558EPA: handling of con_bndrs in mkGadtDecl2022-04-07T12:02:31ZAlan ZimmermanEPA: handling of con_bndrs in mkGadtDeclThere are two minor issues with `mkGadtDecl`
1. A wibble that needs cleaning up by removing the spurious case expression
```haskell
an = case outer_bndrs of
_ -> EpAnn (spanAsAnchor loc) (annsIn ++ annsa) (...There are two minor issues with `mkGadtDecl`
1. A wibble that needs cleaning up by removing the spurious case expression
```haskell
an = case outer_bndrs of
_ -> EpAnn (spanAsAnchor loc) (annsIn ++ annsa) (cs Semi.<> csa)
```
2. When `con_bndrs` are `HsOuterImplicit` we do not print anything while exact printing.
This means the location allocated to it is meaningless, but right now it is set to the entire RHS of the GADT constructor, and this caused issues when re-allocating comments to the nearest enclosing span while exact printing.
I think in that case it should be set to `noSrcSpan`.Alan ZimmermanAlan Zimmermanhttps://gitlab.haskell.org/ghc/ghc/-/issues/20452EPA: Duplicate AnnOpenP/AnnCloseP in DataDecl2021-10-14T19:07:32ZAlan ZimmermanEPA: Duplicate AnnOpenP/AnnCloseP in DataDeclFor the code
```hs
data Proxy (a :: k) = Proxy
```
the parser inserts a duplicate `AnnOpenP` EPA for the opening paren, and likewise for the closing.
The one set is on the `DataDecl`, the other on `KindedTyVar`.For the code
```hs
data Proxy (a :: k) = Proxy
```
the parser inserts a duplicate `AnnOpenP` EPA for the opening paren, and likewise for the closing.
The one set is on the `DataDecl`, the other on `KindedTyVar`.9.2.1Alan ZimmermanAlan Zimmermanhttps://gitlab.haskell.org/ghc/ghc/-/issues/20372EPA : Should there be a Monoid instance for EpAnn payload?2023-10-01T17:42:43ZAlan ZimmermanEPA : Should there be a Monoid instance for EpAnn payload?The `EpAnn` data structure is defined as
```haskell
data EpAnn ann
= EpAnn { entry :: Anchor
, anns :: ann
, comments :: EpAnnComments
}
| EpAnnNotUsed
```
In order to be able to write code...The `EpAnn` data structure is defined as
```haskell
data EpAnn ann
= EpAnn { entry :: Anchor
, anns :: ann
, comments :: EpAnnComments
}
| EpAnnNotUsed
```
In order to be able to write code that for example adds comments to
an arbitrary `EpAnn`, we require a way to make an empty value for the `anns` field.
```haskell
addCommentsToEpAnn loc EpAnnNotUsed cs
= EpAnn (Anchor (realSrcSpan loc) UnchangedAnchor) mempty cs
addCommentsToEpAnn _ (EpAnn a an ocs) ncs = EpAnn a an (ocs <> ncs)
```
To date we have been requiring `Monoid` for this, and using `mempty`.
But, the `(<>)` is never used, and mostly meaningless for combining the actual annotation payloads.
The logical type class to use for this is `Data.Default`, but it is not part of the GHC library set.
What is the best way forward?
- A. Keep it as it is
- B. Use `Data.Default`, and add a copy of it in GHC somewhere
- C. Create a new class playing the role of `Data.Default`.
I suspect option B may cause too many ecosystem knock-on effects, so the real options are A or C.https://gitlab.haskell.org/ghc/ghc/-/issues/20297EPA: comments between 'where' and binds captured in the wrong place2021-10-23T21:19:38ZAlan ZimmermanEPA: comments between 'where' and binds captured in the wrong placeIn the following
```hs
foo = x
where -- do stuff
doStuff = do stuff
```
The `-- do stuff` comment belongs in the binds, it is currently attached to the enclosing `GRHS`.In the following
```hs
foo = x
where -- do stuff
doStuff = do stuff
```
The `-- do stuff` comment belongs in the binds, it is currently attached to the enclosing `GRHS`.9.4.1Alan ZimmermanAlan Zimmermanhttps://gitlab.haskell.org/ghc/ghc/-/issues/20258EPA: order of semicolons and comments for top-level decls is wrong2021-10-23T21:19:38ZAlan ZimmermanEPA: order of semicolons and comments for top-level decls is wrongThe code
```hs
transferCodingStr DeflateTransferCoding = "deflate"
-- Comment 1
-- Comment 2
;
getContentType :: HasHeaders a => a -> Maybe String
```
has the two comments on the annotation for the `getContentType` signature, but the...The code
```hs
transferCodingStr DeflateTransferCoding = "deflate"
-- Comment 1
-- Comment 2
;
getContentType :: HasHeaders a => a -> Maybe String
```
has the two comments on the annotation for the `getContentType` signature, but the semi is attached to the `transferEncoding` declaration.9.4.1Alan ZimmermanAlan Zimmermanhttps://gitlab.haskell.org/ghc/ghc/-/issues/20256EPA: do statement with leading semicolon has wrong anchor2022-05-11T12:54:57ZAlan ZimmermanEPA: do statement with leading semicolon has wrong anchorThe code
```hs
do; a <- doAsync; b
```
Generates an incorrect `Anchor` for the statement list that starts after the first semicolon.The code
```hs
do; a <- doAsync; b
```
Generates an incorrect `Anchor` for the statement list that starts after the first semicolon.9.4.1Alan ZimmermanAlan Zimmerman