ghc-lib-parser 9.12 #1140
Open
ghc-lib-parser 9.12 #1140
+1,021
−306
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
amesgen
force-pushed
the
amesgen/ghc-9.12
branch
2 times, most recently
from
38cb72a to
e9ea55f
Compare
amesgen
force-pushed
the
amesgen/ghc-9.12
branch
from
e9ea55f to
b57e236
Compare
amesgen
force-pushed
the
amesgen/ghc-9.12
branch
from
b57e236 to
2664599
Compare
amesgen
force-pushed
the
amesgen/ghc-9.12
branch
2 times, most recently
from
56c5430 to
ebd4c6a
Compare
amesgen
force-pushed
the
amesgen/ghc-9.12
branch
from
ebd4c6a to
42d3e4d
Compare
amesgen
force-pushed
the
amesgen/ghc-9.12
branch
7 times, most recently
from
44fb942 to
473a86b
Compare
and use GHC 9.10 by default in preparation for ghc-lib-parser 9.12
amesgen
force-pushed
the
amesgen/ghc-9.12
branch
from
473a86b to
f7b371c
Compare
This can only occur with `NoListTuplePuns`. Closes #1146
`FastString`s `Data` instance doesn't look at the underlying data, so our check here will consider all `FastStrings` to be equal. They are used for example for string literals `HsLit`/`HsTyLit`, where we definitely want to make sure that we don't mess up.
amesgen
force-pushed
the
amesgen/ghc-9.12
branch
from
f7b371c to
74fba49
Compare
ncaq
added a commit
to ncaq/fourmolu
that referenced
this pull request
Jan 17, 2025
Address the following GHC breaking changes. [!13511: EPA: Remove AnnKeywordId · Merge requests · Glasgow Haskell Compiler / GHC · GitLab](https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13511) I merge from [ghc-lib-parser 9.12 by amesgen · Pull Request #1140 · tweag/ormolu](tweag/ormolu#1140). This is merely buildable, not fully tested.
ncaq
added a commit
to ncaq/fourmolu
that referenced
this pull request
Jan 17, 2025
Address the following GHC breaking changes. [!13511: EPA: Remove AnnKeywordId · Merge requests · Glasgow Haskell Compiler / GHC · GitLab](https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13511) I merge from [ghc-lib-parser 9.12 by amesgen · Pull Request #1140 · tweag/ormolu](tweag/ormolu#1140). This is merely buildable, not fully tested.
Most examples are taken from the GHC proposal.
amesgen
force-pushed
the
amesgen/ghc-9.12
branch
from
74fba49 to
cf9a8b2
Compare
mrkkrp
reviewed
Jan 22, 2025
CHANGELOG.md
Outdated
| * Switched to `ghc-lib-parser-9.12`, with the following new syntactic features: | ||
| * GHC proposal [#522](https://github.com/ghc-proposals/ghc-proposals/blob/c9401f037cb22d1661931b2ec621925101052997/proposals/0522-or-patterns.rst): `OrPatterns` (enabled by default) | ||
| * GHC proposal [#569](https://github.com/ghc-proposals/ghc-proposals/blob/c9401f037cb22d1661931b2ec621925101052997/proposals/0569-multiline-strings.rst): `MultilineStrings` (disabled by default) | ||
| * GHC proposal [#409](https://github.com/ghc-proposals/ghc-proposals/blob/c9401f037cb22d1661931b2ec621925101052997/proposals/0569-multiline-strings.rst): `NamedDefaults` (enabled by default) |
There was a problem hiding this comment.
Is the link for NamedDefaults incorrect? It is pointing to the multiline strings proposal.
There was a problem hiding this comment.
Thanks, fixed in 7eb8c79
| where | ||
| leadingSpace = T.length $ T.takeWhile is_space l | ||
|
|
||
| -- | The start/end marker of the literal, whether it is a regular or a multiline |
There was a problem hiding this comment.
Can we put the type definitions at the top?
| -- | The start/end marker of the literal, whether it is a regular or a multiline | ||
| -- literal, and the segments of the literals (separated by gaps for a regular | ||
| -- literal, and separated by newlines for a multiline literal). | ||
| type ParsedStringLiteral = StringLiteralData (StringLiteralKind [Text]) |
There was a problem hiding this comment.
Would this be simpler?
data ParsedStringLiteral = ParsedStringLiteral
{ startMarker, endMarker :: Text,
content :: [Text],
stringLiteralKind :: StringLiteralKind
}
data StringLiteralKind = RegularStringLiteral | MultilineStringLiteralThere was a problem hiding this comment.
I adopted this in 635b354
StringLiteralKind was parametric such that stripStartEndMarker could return StringLiteralKind Text (compared to StringLiteralKind [Text] for ParsedStringLiteral). I changed it such that stripStartEndMarker now returns a singleton list, which seems is fine, and it simplifies the data flow a bit I think.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See the new changelog entries for details.
The commits can be reviewed individually.
Also closes #1146, closes #1152
Also upgrade cabal and enable
multi-repl, soghcidwill now work across all components out of the box!