GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2024-03-27T03:14:14Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/24596missing export lists warning gives wrong line2024-03-27T03:14:14ZHateUsernamesmissing export lists warning gives wrong line## Summary
When compiling a file that has LANGUAGE or OPTIONS_GHC pragmas at the top the warning `-Wmissing-export-lists` gives the incorrect line number.
```txt
DB/Command.hs:1:1: error: [-Wmissing-export-lists, -Werror=missing-export...## Summary
When compiling a file that has LANGUAGE or OPTIONS_GHC pragmas at the top the warning `-Wmissing-export-lists` gives the incorrect line number.
```txt
DB/Command.hs:1:1: error: [-Wmissing-export-lists, -Werror=missing-export-lists]
The export item ‘module DB.Command’ is missing an export list
|
1 | {-# LANGUAGE Unsafe #-}
| ^
```
## Steps to reproduce
```sh
echo '{-# LANGUAGE Unsafe #-}\nmodule ABC where\n' > /tmp/mxl.hs
ghc -Wmissing-export-lists -Werror /tmp/mxl.hs
```
## Expected behavior
```txt
Loaded package environment from /home/wjr/.ghc/x86_64-openbsd-9.2.7/environments/default
[1 of 1] Compiling ABC ( /tmp/mxl.hs, /tmp/mxl.o )
/tmp/mxl.hs:1:1: error: [-Wmissing-export-lists, -Werror=missing-export-lists]
The export item ‘module ABC’ is missing an export list
|
1 | {-# LANGUAGE Unsafe #-}
| ^
```
## Environment
* GHC version used: 9.2.7
Optional:
* Operating System: OpenBSD 7.4
* System Architecture: x86_64https://gitlab.haskell.org/ghc/ghc/-/issues/24557TypeAbstractions doesn't parse with \case, but does parse with \cases2024-03-28T08:53:38ZRyan ScottTypeAbstractions doesn't parse with \case, but does parse with \casesI am using GHC 9.10.1-alpha1, which introduces `@`-binders in more places in pattern contexts (https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11109). Based on one of the test cases added in that MR, I discovered that `TypeAbstractio...I am using GHC 9.10.1-alpha1, which introduces `@`-binders in more places in pattern contexts (https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11109). Based on one of the test cases added in that MR, I discovered that `TypeAbstractions` could be combined with `LambdaCase`, e.g.,
```hs
{-# LANGUAGE GHC2024 #-}
{-# LANGUAGE TypeAbstractions #-}
module Foo where
import Data.Kind
f :: (forall (a :: Type). ()) -> ()
f k = k @Bool
g :: ()
g = f (\cases
@a -> ())
```
Great. What is surprising, however, is that if I change `\cases` to be `\case`:
```hs
g :: ()
g = f (\case
@a -> ())
```
Then GHC fails to parse it:
```
$ ghc-9.10 Foo.hs
[1 of 1] Compiling Foo ( Foo.hs, Foo.o )
Foo.hs:11:8: error: [GHC-06074]
Unexpected \case expression in function application:
\case
Suggested fixes:
• Use parentheses.
• Perhaps you intended to use BlockArguments
|
11 | g = f (\case
| ^
Foo.hs:11:8: error: [GHC-66228]
View pattern in expression context: \case @a -> ()
|
11 | g = f (\case
| ^^^^^...
```
This feels inconsistent, as I would expect that if `\cases` works, then `\case` should also work. Is this intended?https://gitlab.haskell.org/ghc/ghc/-/issues/24469Lexer is too permissive with numbers followed by an identifier (e.g. "1foo")2024-02-28T18:22:40ZVaibhav SagarLexer is too permissive with numbers followed by an identifier (e.g. "1foo")## Summary
GHC's lexer lexes numbers followed by an identifier as two separate tokens (number and then identifier) when I think it should reject this as invalid.
## Steps to reproduce
```
GHCi, version 9.8.1: https://www.haskell.org/g...## Summary
GHC's lexer lexes numbers followed by an identifier as two separate tokens (number and then identifier) when I think it should reject this as invalid.
## Steps to reproduce
```
GHCi, version 9.8.1: https://www.haskell.org/ghc/ :? for help
ghci> foo = 1
ghci> (+) 1foo
2
```
## Expected behavior
I would expect the lexer to throw an error.
## Environment
* GHC version used: 9.8.1
Optional:
* Operating System:
* System Architecture:https://gitlab.haskell.org/ghc/ghc/-/issues/24439Parser: use left-recursion in apats and argpats2024-02-20T14:38:06ZVladislav ZavialovParser: use left-recursion in apats and argpatsThe following discussion from !11109 should be addressed:
- [ ] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11109#note_521826
> Happy works better with left-recursive grammars, so I expected to see
>
> ```
> ar...The following discussion from !11109 should be addressed:
- [ ] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11109#note_521826
> Happy works better with left-recursive grammars, so I expected to see
>
> ```
> argpats :: { [LArgPat GhcPs] } -- reversed
> : argpats argpat { $2 : $1 }
> | { [] }
> ```
>
> But then I noticed that `apats` has the same problem, and you probably simply used it as a reference.
>
> We should fix this at some point, but maybe not in this patch.https://gitlab.haskell.org/ghc/ghc/-/issues/24429Missplaced overlapping pragmas make module misparse2024-02-13T15:41:17ZOleg GrenrusMissplaced overlapping pragmas make module misparse```haskell
module Issue where
{-# overlapping is better avoided #-}
class Foo a where
foo :: a
```
```
[1 of 1] Compiling Issue ( Issue.hs, interpreted )
Issue.hs:3:1: error: [GHC-58481]
parse error on input ‘{-# ov...```haskell
module Issue where
{-# overlapping is better avoided #-}
class Foo a where
foo :: a
```
```
[1 of 1] Compiling Issue ( Issue.hs, interpreted )
Issue.hs:3:1: error: [GHC-58481]
parse error on input ‘{-# overlapping’
|
3 | {-# overlapping is better avoided #-}
| ^^^^^^^^^^^^^^^
```https://gitlab.haskell.org/ghc/ghc/-/issues/24351Parser: Make use of `happy`'s `%error` declaration to get suggestions for val...2024-02-21T21:16:20ZSebastian GrafParser: Make use of `happy`'s `%error` declaration to get suggestions for valid tokens at error positionhttps://haskell-happy.readthedocs.io/en/latest/syntax.html#error-declaration
It appears that `happy` has some limited support for suggesting valid tokens at an error position.
For that we'd simply say
```
%error GHC.Parser.Lexer.srcPars...https://haskell-happy.readthedocs.io/en/latest/syntax.html#error-declaration
It appears that `happy` has some limited support for suggesting valid tokens at an error position.
For that we'd simply say
```
%error GHC.Parser.Lexer.srcParseFail
%errorhandlertype explist
```
and where currently in GHC.Parser.Lexer we have:
```hs
-- Report a parse failure, giving the span of the previous token as
-- the location of the error. This is the entry point for errors
-- detected during parsing.
srcParseFail :: P a
srcParseFail = P $ \s@PState{ buffer = buf, options = o, last_len = len,
last_loc = last_loc } ->
unP (addFatalError $ srcParseErr o buf len (mkSrcSpanPs last_loc)) s
```
we'd refactor to
```hs
-- Report a parse failure, giving the span of the previous token as
-- the location of the error. This is the entry point for errors
-- detected during parsing.
srcParseFail :: [String] -> Located Token -> P a
srcParseFail expected last_loc =
P $ \s@PState{ buffer = buf, options = o, last_len = len } ->
unP (addFatalError $ srcParseErr o buf len (mkSrcSpanPs last_loc)) s
```
and perhaps consider `expected` when generating the `srcParseErr`. (I find it a bit strange to generate a `[String]` rather than `[Token]` here, but that's the `happy` we have to live with.)https://gitlab.haskell.org/ghc/ghc/-/issues/24250OverloadedLabels "lexical error in pragma" when using a bare number2023-12-13T21:24:14ZAdam GundryOverloadedLabels "lexical error in pragma" when using a bare numberWhen `OverloadedLabels` is in use, if a label is immediately followed by a digit in a GHCi expression, a "lexical error in pragma" message results, even though this should be parsed successfully:
```haskell
GHCi, version 9.8.0.20230727:...When `OverloadedLabels` is in use, if a label is immediately followed by a digit in a GHCi expression, a "lexical error in pragma" message results, even though this should be parsed successfully:
```haskell
GHCi, version 9.8.0.20230727: https://www.haskell.org/ghc/ :? for help
ghci> :set -XOverloadedLabels
ghci> :t #x
#x :: GHC.OverloadedLabels.IsLabel "x" a => a
ghci> :t #2
<interactive>:1:2: error: [GHC-21231]
lexical error in pragma at character '2'
```
Surrounding the label in parentheses works around the problem, and it doesn't seem to happen for non-digit characters:
```haskell
ghci> :t (#2)
(#2) :: GHC.OverloadedLabels.IsLabel "2" a => a
ghci> :t #'
#' :: GHC.OverloadedLabels.IsLabel "'" a => a
```https://gitlab.haskell.org/ghc/ghc/-/issues/23935Empty Haddock comments no longer occur in the AST as `HsDoc`2023-09-14T19:20:21ZamesgenEmpty Haddock comments no longer occur in the AST as `HsDoc`## Summary
Consider the following two type signatures.
```haskell
foo :: {- |-} A -> B
bar :: {- | -} A -> B
```
Comparing the AST (with `-haddock`) of `foo` and `bar`, note that `foo` does not contain a `HsDoc` (searchf or `WithHsDocId...## Summary
Consider the following two type signatures.
```haskell
foo :: {- |-} A -> B
bar :: {- | -} A -> B
```
Comparing the AST (with `-haddock`) of `foo` and `bar`, note that `foo` does not contain a `HsDoc` (searchf or `WithHsDocIdentifiers`), but `bar` does:
<table>
<tr><th>
`foo`</th><th>
`bar`</th></tr>
<tr>
<td>
```haskell
(L
(SrcSpanAnn (EpAnn
(Anchor
{ <interactive>:1:1-20 }
(UnchangedAnchor))
(AnnListItem
[])
(EpaComments
[])) { <interactive>:1:1-20 })
(SigD
(NoExtField)
(TypeSig
(EpAnn
(Anchor
{ <interactive>:1:1-3 }
(UnchangedAnchor))
(AnnSig
(AddEpAnn AnnDcolon (EpaSpan { <interactive>:1:5-6 }))
[])
(EpaComments
[]))
[(L
(SrcSpanAnn (EpAnnNotUsed) { <interactive>:1:1-3 })
(Unqual
{OccName: foo}))]
(HsWC
(NoExtField)
(L
(SrcSpanAnn (EpAnnNotUsed) { <interactive>:1:15-20 })
(HsSig
(NoExtField)
(HsOuterImplicit
(NoExtField))
(L
(SrcSpanAnn (EpAnnNotUsed) { <interactive>:1:15-20 })
(HsFunTy
(EpAnn
(Anchor
{ <interactive>:1:15 }
(UnchangedAnchor))
(NoEpAnns)
(EpaComments
[]))
(HsUnrestrictedArrow
(L
(TokenLoc
(EpaSpan { <interactive>:1:17-18 }))
(HsNormalTok)))
(L
(SrcSpanAnn (EpAnnNotUsed) { <interactive>:1:15 })
(HsTyVar
(EpAnn
(Anchor
{ <interactive>:1:15 }
(UnchangedAnchor))
[]
(EpaComments
[]))
(NotPromoted)
(L
(SrcSpanAnn (EpAnnNotUsed) { <interactive>:1:15 })
(Unqual
{OccName: A}))))
(L
(SrcSpanAnn (EpAnnNotUsed) { <interactive>:1:20 })
(HsTyVar
(EpAnn
(Anchor
{ <interactive>:1:20 }
(UnchangedAnchor))
[]
(EpaComments
[]))
(NotPromoted)
(L
(SrcSpanAnn (EpAnnNotUsed) { <interactive>:1:20 })
(Unqual
{OccName: B}))))))))))))
```
</td>
<td>
```haskell
(L
(SrcSpanAnn (EpAnn
(Anchor
{ <interactive>:1:1-21 }
(UnchangedAnchor))
(AnnListItem
[])
(EpaComments
[])) { <interactive>:1:1-21 })
(SigD
(NoExtField)
(TypeSig
(EpAnn
(Anchor
{ <interactive>:1:1-3 }
(UnchangedAnchor))
(AnnSig
(AddEpAnn AnnDcolon (EpaSpan { <interactive>:1:5-6 }))
[])
(EpaComments
[]))
[(L
(SrcSpanAnn (EpAnnNotUsed) { <interactive>:1:1-3 })
(Unqual
{OccName: bar}))]
(HsWC
(NoExtField)
(L
(SrcSpanAnn (EpAnnNotUsed) { <interactive>:1:16-21 })
(HsSig
(NoExtField)
(HsOuterImplicit
(NoExtField))
(L
(SrcSpanAnn (EpAnnNotUsed) { <interactive>:1:16-21 })
(HsFunTy
(EpAnn
(Anchor
{ <interactive>:1:16 }
(UnchangedAnchor))
(NoEpAnns)
(EpaComments
[]))
(HsUnrestrictedArrow
(L
(TokenLoc
(EpaSpan { <interactive>:1:18-19 }))
(HsNormalTok)))
(L
(SrcSpanAnn (EpAnnNotUsed) { <interactive>:1:16 })
(HsDocTy
(EpAnnNotUsed)
(L
(SrcSpanAnn (EpAnnNotUsed) { <interactive>:1:16 })
(HsTyVar
(EpAnn
(Anchor
{ <interactive>:1:16 }
(UnchangedAnchor))
[]
(EpaComments
[]))
(NotPromoted)
(L
(SrcSpanAnn (EpAnnNotUsed) { <interactive>:1:16 })
(Unqual
{OccName: A}))))
(L
{ <interactive>:1:8-14 }
(WithHsDocIdentifiers
(NestedDocString
(HsDocStringNext)
(L
{ <interactive>:1:8-14 }
(HsDocStringChunk
" ")))
[]))))
(L
(SrcSpanAnn (EpAnnNotUsed) { <interactive>:1:21 })
(HsTyVar
(EpAnn
(Anchor
{ <interactive>:1:21 }
(UnchangedAnchor))
[]
(EpaComments
[]))
(NotPromoted)
(L
(SrcSpanAnn (EpAnnNotUsed) { <interactive>:1:21 })
(Unqual
{OccName: B}))))))))))))
```
</td>
</tr>
</table>
Is there a particular reason for this? In GHC 8.10, the AST contained Haddock comments in both cases.
Concrete effects of this behavior:
- It makes the job of formatters like Ormolu (see issues [1068](https://github.com/tweag/ormolu/pull/1068), [1065](https://github.com/tweag/ormolu/issues/1065), [726](https://github.com/tweag/ormolu/issues/726)) that check of AST discrepancies automatically harder than necessary, as eg a natural rewrite from
```haskell
foo ::
-- |
--
A ->
B
```
to
```haskell
foo ::
-- |
A ->
B
```
contains a Haddock comment in the AST in the first snippet, but not in the second.
- A nice Haddock trick by @tomjaguarpaw1 ([blog post](http://h2.jaguarpaw.co.uk/posts/improving-the-typed-process-documentation/), search for "Forced type signatures to wrap") does [no longer work](https://github.com/tweag/ormolu/pull/1068#issuecomment-1707237587).
Ideally, the behavior would be changed as it was in 8.10; I could try to do that in case this behavior is not intentional.
## Environment
* GHC version used: Any GHC since 9.0 (I think this change is due to !2377)https://gitlab.haskell.org/ghc/ghc/-/issues/23624Parse error on `COLUMN` pragma before first token2023-07-17T18:53:26ZSimon Hengelsol@typeful.netParse error on `COLUMN` pragma before first token## Summary
When I use a `COLUMN` pragma before the first token I get a parse error.
## Steps to reproduce
```haskell
{-# LANGUAGE OverloadedStrings #-}
-- module Main where
{-# LINE 8 "Foo.hs" #-}
{-# COLUMN 17 #-}import qualified {-...## Summary
When I use a `COLUMN` pragma before the first token I get a parse error.
## Steps to reproduce
```haskell
{-# LANGUAGE OverloadedStrings #-}
-- module Main where
{-# LINE 8 "Foo.hs" #-}
{-# COLUMN 17 #-}import qualified {-# COLUMN 17 #-}Data.Text
main :: IO ()
main = print $ Data.Text.length "foo"
```
```
$ runhaskell Main.hs
Foo.hs:10:1: error: [GHC-58481] parse error on input ‘main’
```
If I uncomment the module header then the program is accepted.
## Expected behavior
The program should be accepted.
## Environment
* GHC version used: 9.6.1Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/23297Incorrect(?) suggestion with ticket constructors and `-Woperator-whitespace`2023-11-28T15:34:02ZRebecca TurnerIncorrect(?) suggestion with ticket constructors and `-Woperator-whitespace`## Summary
With `-Weverything`, the `-Woperator-whitespace` lint suggests changing a ticked constructor from `foo ':<>: bar` to `foo ' :<>: bar`.
## Steps to reproduce
With `OperatorWhitespace.hs`:
```haskell
{-# LANGUAGE DataKinds #...## Summary
With `-Weverything`, the `-Woperator-whitespace` lint suggests changing a ticked constructor from `foo ':<>: bar` to `foo ' :<>: bar`.
## Steps to reproduce
With `OperatorWhitespace.hs`:
```haskell
{-# LANGUAGE DataKinds #-}
module OperatorWhitespace () where
import GHC.TypeLits (TypeError, ErrorMessage(Text, (:<>:)))
type MyError :: forall k. k
type MyError = TypeError ('Text "Error" ':<>: 'Text "Error")
```
Compiling the file gives this warning (maybe a mis-parse?)
```ShellSession
$ ghc -Weverything OperatorWhitespace.hs
OperatorWhitespace.hs:8:42: warning: [GHC-40798] [-Woperator-whitespace]
The suffix use of a ‘:<>:’ might be repurposed as special syntax
by a future language extension.
Suggested fix: Add whitespace around ‘:<>:’.
|
8 | type MyError = TypeError ('Text "Error" ':<>: 'Text "Error")
| ^^^^
```
The lint goes away when I change it to `type MyError = TypeError ('Text "Error" ' :<>: 'Text "Error")`.
## Expected behavior
Adding whitespace between the operator and the promotion tick looks really weird. Surely this isn't the intended syntax?
```haskell
type MyError = TypeError ('Text "Error" ' :<>: 'Text "Error")
```
I would expect `':<>:` to parse correctly without warnings.
## Environment
* GHC version used: 9.6.1
```
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 9.6.1
```
Optional:
* Operating System: macOS
* System Architecture: aarch64
```ShellSession
$ uname -a
Darwin san-fransisco 22.4.0 Darwin Kernel Version 22.4.0: Mon Mar 6 20:59:28 PST 2023; root:xnu-8796.101.5~3/RELEASE_ARM64_T6000 arm64
```Vladislav ZavialovVladislav Zavialovhttps://gitlab.haskell.org/ghc/ghc/-/issues/23040`OverloadedRecordDot` and `COLUMN`-pragmas don't play nice together2023-02-28T15:27:27ZSimon Hengelsol@typeful.net`OverloadedRecordDot` and `COLUMN`-pragmas don't play nice together## Summary
`foo.foo` is accepted while `foo{-# COLUMN 23 #-}.foo` results in a parse error.
This is surprising from a users perspective and can break `OverloadedRecordDot` with source-to-source transformations / pre-processors (as it d...## Summary
`foo.foo` is accepted while `foo{-# COLUMN 23 #-}.foo` results in a parse error.
This is surprising from a users perspective and can break `OverloadedRecordDot` with source-to-source transformations / pre-processors (as it does for me).
## Steps to reproduce
```
{-# LANGUAGE NoFieldSelectors #-}
{-# LANGUAGE OverloadedRecordDot #-}
data Foo = Foo { foo :: String }
foo :: Foo
foo = Foo "foo"
main :: IO ()
main = do
putStrLn foo.foo -- works
putStrLn foo{-# COLUMN 23 #-}.foo -- parse error
```
## Expected behavior
Both `foo.foo` and `foo{-# COLUMN 23 #-}.foo` should be accepted.
## Investigation
`foo.foo` is tokenized to:
[ITvarid "foo", ITproj False, ITvarid "bar"]
However, `foo{-# COLUMN 23 #-}.foo` is tokenized to:
[ITvarid "foo", ITproj True, ITvarid "bar"]
So from what I understand, even though this manifests as a parse error, the bug is actually in the lexer.
## Environment
* GHC version used: 9.6.0.20230111
Optional:
* Operating System: Linux
* System Architecture: x86_64https://gitlab.haskell.org/ghc/ghc/-/issues/22980Parser: The BitMap of reservedWordsFM doesn't work well with extension sugges...2023-06-18T12:57:09ZSebastian GrafParser: The BitMap of reservedWordsFM doesn't work well with extension suggestions.While figuring out Or patterns with @knothed, we added a new contextual keyword `one` (as in the Or pattern `(one of LT, EQ)`). The natural choice was to add the following entry to `reservedWordsFM` in the Lexer:
```hs
+ ( "one"...While figuring out Or patterns with @knothed, we added a new contextual keyword `one` (as in the Or pattern `(one of LT, EQ)`). The natural choice was to add the following entry to `reservedWordsFM` in the Lexer:
```hs
+ ( "one", ITone, xbit OrPatternsBit),
```
Note the usage of `xbit` instead of merely `0`. The latter would indicate that this keyword is always active.
Alas, although that fixes rejecting `one` as an identifier when `-XOrPatterns` is not active, it also regresses in usability, because now when the user writes an Or pattern, she no longer sees the suggestion to enable `-XOrPatterns`!
So what David did (in !9229) was to have
```hs
+ ( "one", ITone, 0),
```
*and* add a production to `special_id` in the Parser:
```
special_id
: ...
| 'prim' { sL1 $1 (fsLit "prim") }
+ | 'one' { sL1 $1 (fsLit "one") }
| 'javascript' { sL1 $1 (fsLit "javascript") }
...
```
Now we get good suggestions *and* won't gobble up `one` (unless it's in a pattern and followed by the keyword `of`).
I think `Note [Lexing type pseudo-keywords]` argues similarly for keywords such as `role`, `family` etc. Strangely, it adds the production to `varid` directly instead of `special_ids`, where it would fit better, IMO. Doesn't matter much though.
# Proposal
We should
1. Identify extension keywords that can benefit from this procedure, which is:
> Pretend that the extension is enabled and fall back to a `special_id` production if the parse of the extended syntax was unsuccessful. Otherwise reject and suggest to enable the extension
As an example, I recall that the suggestion for pattern synonyms does not work ATM. Perhaps we could make it work.
2. In the unlikely event that all `xbit` can be removed from `reservedWordsFM`, simplify.
3. Document the procedure above and how to judge whether it applies to Your Extension
4. Move the type pseudo-keywords to `special_ids` productions
CC @int-index who seems to have worked on this in the past.https://gitlab.haskell.org/ghc/ghc/-/issues/22733Undocumented feature of WARNING pragmas2023-01-30T13:05:54ZAdam GundryUndocumented feature of WARNING pragmasI discovered by reading the parser that the following syntax is accepted for multiple warnings within a single `WARNING` or `DEPRECATED` pragma:
```hs
{-# WARNING foo "foo is dangerous" ;
bar "bar is mostly harmless" #-}
foo,...I discovered by reading the parser that the following syntax is accepted for multiple warnings within a single `WARNING` or `DEPRECATED` pragma:
```hs
{-# WARNING foo "foo is dangerous" ;
bar "bar is mostly harmless" #-}
foo, bar :: ()
foo = foo
bar = ()
```
This seems a bit strange, as one could simply write multiple separate `WARNING` pragmas. It doesn't appear to be documented in the user's guide (https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/pragmas.html#warning-and-deprecated-pragmas). We should document this, or could we remove the feature entirely?https://gitlab.haskell.org/ghc/ghc/-/issues/22646Template Haskell apostrophes and Magic Hash inferrence2022-12-20T18:14:43ZBenjamin McRaeTemplate Haskell apostrophes and Magic Hash inferrence<!--
READ THIS FIRST: If the feature you are proposing changes the language that GHC accepts
or adds any warnings to `-Wall`, it should be written as a [GHC Proposal](https://github.com/ghc-proposals/ghc-proposals/).
Other features, appr...<!--
READ THIS FIRST: If the feature you are proposing changes the language that GHC accepts
or adds any warnings to `-Wall`, it should be written as a [GHC Proposal](https://github.com/ghc-proposals/ghc-proposals/).
Other features, appropriate for a GitLab feature request, include GHC API/plugin
innovations, new low-impact compiler flags, or other similar additions to GHC.
-->
## Motivation
When using template haskell, one can use `''TypeName` to name a type as a value. In some cases, a magic value with a magic hash (such as `SmallArray#` from GHC.Prim) may want to be used in this case. When `''SmallArray#` is written, mistakenly not enabling MagicHash results in some confusing errors:
```
/path/to/file.hs:72:12: error:
• Not in scope: type constructor or class ‘SmallArray’
Perhaps you meant ‘SmallArray#’ (imported from GHC.Prim)
• In the Template Haskell quotation ''SmallArray
|
72 | , (''SmallArray#, Just [Strict])
| ^^^^^^^^^^^^
/path/to/file.hs:72:12: error:
A section must be enclosed in parentheses thus: (''SmallArray #)
|
72 | , (''SmallArray#, Just [Strict])
| ^^^^^^^^^^^^^
Progress 1/2
```
## Proposal
Ideally when presented like a scenario like this, GHC should recommend enabling the MagicHash extension, instead of these two suggestions which are both not useful here.https://gitlab.haskell.org/ghc/ghc/-/issues/22412Feature Idea: Conflict Marker detection and reporting in source files2022-11-23T17:16:54ZHécate MoonlightFeature Idea: Conflict Marker detection and reporting in source filesAs so helpfully pointed out by @phadej, Clang is able to produce a helpful report when detecting version control conflict markers in a source file:
![image](/uploads/328b67b663a49536a8f2408d0244bb5f/image.png)
I believe it would be a w...As so helpfully pointed out by @phadej, Clang is able to produce a helpful report when detecting version control conflict markers in a source file:
![image](/uploads/328b67b663a49536a8f2408d0244bb5f/image.png)
I believe it would be a welcome addition from our users, and would certainly help with GHC's reputation to the general public.
Here are relevant links from the clang source file:
* [Lexer.cpp#L4028-L4032](https://github.com/llvm/llvm-project/blob/369899449226a00f15422a12aacb62dee312c8d5/clang/lib/Lex/Lexer.cpp#L4028-L4032)
* [Lexer.h#L42-L55](https://github.com/llvm/llvm-project/blob/369899449226a00f15422a12aacb62dee312c8d5/clang/include/clang/Lex/Lexer.h#L42-L55)
* [Lexer.cpp#L3077-L3156](https://github.com/llvm/llvm-project/blob/2e999b7dd1934a44d38c3a753460f1e5a217e9a5/clang/lib/Lex/Lexer.cpp#L3077-L3156)
* [DiagnosticLexKinds.td#L97](https://github.com/llvm/llvm-project/blob/2e999b7dd1934a44d38c3a753460f1e5a217e9a5/clang/include/clang/Basic/DiagnosticLexKinds.td#L97)https://gitlab.haskell.org/ghc/ghc/-/issues/22173Heuristic and helpful message for layout/indentation errors2022-09-15T16:01:33ZmniipHeuristic and helpful message for layout/indentation errors## Motivation
Parse errors caused by incorrect layout are notoriously opaque. Currently if a parse error happens on a token that happens to be a virtual token inserted according to layout rules, we merely guess that it is indentation-re...## Motivation
Parse errors caused by incorrect layout are notoriously opaque. Currently if a parse error happens on a token that happens to be a virtual token inserted according to layout rules, we merely guess that it is indentation-related. Otherwise we don't mention indentation at all.
Often incorrect layout will cause the parser to descend down an incorrect sequence of productions, meaning it will report an error at a point after the layout token (#12483, #19097), meaning GHC will not even offer indentation as a possible cause.
Also related: #16955 #17028
## Proposal
When there is a parse error, in certain circumstances we somehow inform the user of the virtual layout tokens that we saw recently.
Supposing the code was something like
```hs
do
let x = case () of
pat -> ()
...
```
and we somehow told the user that, actually, `case of` ended before `pat`, they would immediately recognize that this is not what they meant to write. They might not know how to write the correct thing (and I'm not sure we can offer a concrete fix in the general case), but at least they will know that it's probably not related to the `BlockArguments` suggestion, nor the spelling of the `->`.
For what the "certain circumstances" are -- the parse error could be arbitrarily far away from the responsible layout token, and I do not have a complete/satisfying answer for this. However `srcParseErr` already comes with a couple heuristics in lieu of "was there a suspicious thing in the last N chars?", and we could continue with that for a heuristic that could work well enough: if there has been a virtual closing brace or virtual semicolon in the last N tokens (I don't know of a layout error that's caused by a virtual opening brace).
As for the "somehow inform" -- an obvious option here seems to be to print some of the most recent tokens we've seen, inserting and highlighting (color?) the virtual ones.
How many tokens do we print? Again the real responsible layout token could be arbitrarily far back, but not so far that there has been an entire top-level declaration inbetween. If we parsed all the way to `module M where{ ... A;B;C` then we assume that B is correctly separated from A, and thus a parse error in C cannot be related to A (could however be related to B being incorrectly separated from C). Similarly if there's explicit braces/semicolons we don't have to look past those.
Still that may be arbitrarily many tokens, thus arbitrarily much memory so we may want to introduce an arbitrary cutoff at N tokens.
It is noteworthy that the "source location" at which virtual tokens are inserted is immediately preceding whatever token comes after, meaning typical code would turn into something like
```hs
...
;x = case () of
{pat -> ()
};y = y
;...
```
which is amazingly bad. One possible solution here is to reindent the tokens based on real and virtual braces/semicolons (which will additionally highlight their structure), ignoring user-provided whitespace, thus:
```hs
{ ...
; x = case () of
{ pat -> ()
}
; y = y
; ...
}
```
People unfamiliar with haskell might hate this. A less complicated solution is to move the virtual tokens past all preceding whitespace:
```hs
...;
x = case () of{
pat -> ()};
y = y;
...
```https://gitlab.haskell.org/ghc/ghc/-/issues/22155HexFloatLiterals doesn't parse for unboxed Float# and Double# literals2022-09-13T13:26:08ZDavid Orion GirardoHexFloatLiterals doesn't parse for unboxed Float# and Double# literalsIn ghc 9.4.2 (reproduced in both ghci and ghc single-file mode)
Test.hs:
```
{-# language HexFloatLiterals, MagicHash #-}
module Test where
import GHC.Types
a = D# 0x1p0##
```
complains
```
Test.hs:6:1: error:
parse error (possib...In ghc 9.4.2 (reproduced in both ghci and ghc single-file mode)
Test.hs:
```
{-# language HexFloatLiterals, MagicHash #-}
module Test where
import GHC.Types
a = D# 0x1p0##
```
complains
```
Test.hs:6:1: error:
parse error (possibly incorrect indentation or mismatched brackets)
```
but replacing it with `a = D# 1.0##` or `a = 0x1p0 :: Double` is fine.
Similarly for floats.Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/22088Misleading parser error when `else` branch is missing2024-02-20T19:53:25ZAlex DMisleading parser error when `else` branch is missingif I say
```
foo :: ()
foo = if True then ()
```
I get
```
parse error (possibly incorrect indentation or mismatched brackets)
```
Is it possible to suggest a more useful `missing 'else'` error message?if I say
```
foo :: ()
foo = if True then ()
```
I get
```
parse error (possibly incorrect indentation or mismatched brackets)
```
Is it possible to suggest a more useful `missing 'else'` error message?https://gitlab.haskell.org/ghc/ghc/-/issues/22045Allowed character sets for bindings/patterns/types are inconsistent2022-09-23T01:03:03ZAlexandre EstevesAllowed character sets for bindings/patterns/types are inconsistent```haskell
{-# LANGUAGE PatternSynonyms #-}
main :: IO ()
main = pure ()
data Pair a b = Pair a b
(###) :: a -> b -> Pair a b -- OK
(###) a b = Pair a b -- OK
a ### b = Pair a b -- OK
pattern (###) :: a -> b -> Pair a b -- error: parse...```haskell
{-# LANGUAGE PatternSynonyms #-}
main :: IO ()
main = pure ()
data Pair a b = Pair a b
(###) :: a -> b -> Pair a b -- OK
(###) a b = Pair a b -- OK
a ### b = Pair a b -- OK
pattern (###) :: a -> b -> Pair a b -- error: parse error on input ‘###’
pattern a ### b = Pair a b -- error: parse error on input ‘###’
(???) :: a -> b -> Pair a b -- OK
(???) a b = Pair a b -- OK
a ??? b = Pair a b -- OK
pattern (???) :: a -> b -> Pair a b -- error: parse error on input ‘???’
pattern a ??? b = Pair a b -- error: parse error on input ‘???’
(:::) :: a -> b -> Pair a b -- Invalid type signature: (:::) :: ... Should be of form <variable> :: <type>
(:::) a b = Pair a b -- OK
a ::: b = Pair a b -- OK
pattern (:::) :: a -> b -> Pair a b -- OK
pattern a ::: b = Pair a b -- OK
```
## Expected behavior
I would expect the same character sets to be allowed in bindings and patterns. At least https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/pattern_synonyms.html doesn't give me evidence otherwise.
I also would expect bindings and their signatures to allow the same character sets.
## Environment
* GHC version used: happens both on 8.6.5 and 9.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/21982Confusing error and location when nesting lambdas and do-blocks2022-08-09T13:57:40ZValentin Robertval@galois.comConfusing error and location when nesting lambdas and do-blocks## Summary
I was in the process of refactoring a large pattern match of the form:
```haskell
{-# LANGUAGE UnicodeSyntax #-}
module BadErrorLocation where
import Data.Functor.Identity (Identity(..))
data T = A | B | C | D
f t =
\...## Summary
I was in the process of refactoring a large pattern match of the form:
```haskell
{-# LANGUAGE UnicodeSyntax #-}
module BadErrorLocation where
import Data.Functor.Identity (Identity(..))
data T = A | B | C | D
f t =
\ x → do
case t of
A → do
a ← runIdentity (Identity 0)
return a
B → do
a ← runIdentity (Identity 0)
return a
C → do
a ← runIdentity (Identity 0)
return a
D → do oops
a ← runIdentity (Identity 0)
return a
```
```
BadErrorLocation.hs:12:11: error: do-notation in pattern
|
12 | A → do
| ^^^...
```
Notice how I accidentally left an `oops` on the `do` line of the `D` branch. Unfortunately, this reports an error on the `A` branch line. In my real example, there were of course a couple dozen lines between these two, so figuring out where the error was became sort of a binary search on the AST...
## Steps to reproduce
Just drop the above in a file.
## Expected behavior
Some error on the `D → do oops` line ideally. No error on the `A → do` line.
If you remove the `\ x → do` block altogether, you'll see the error reported is better.
## Environment
* GHC version used:
Confirmed on:
- 8.10.7
- 9.2.2ZubinZubin