[Git][ghc/ghc][wip/disamb-td] 7 commits: Refactor CLabel pretty-printing
Vladislav Zavialov
gitlab at gitlab.haskell.org
Tue Aug 4 21:24:41 UTC 2020
Vladislav Zavialov pushed to branch wip/disamb-td at Glasgow Haskell Compiler / GHC
Commits:
56a7c193 by Sylvain Henry at 2020-07-31T19:32:09+02:00
Refactor CLabel pretty-printing
Pretty-printing CLabel relies on sdocWithDynFlags that we want to remove
(#10143, #17957). It uses it to query the backend and the platform.
This patch exposes Clabel ppr functions specialised for each backend so
that backend code can directly use them.
- - - - -
3b15dc3c by Sylvain Henry at 2020-07-31T19:32:09+02:00
DynFlags: don't use sdocWithDynFlags in GHC.CmmToAsm.Dwarf.Types
- - - - -
e30fed6c by Vladislav Zavialov at 2020-08-01T04:23:04-04:00
Test case for #17652
The issue was fixed by 19e80b9af252eee760dc047765a9930ef00067ec
- - - - -
22641742 by Ryan Scott at 2020-08-02T16:44:11-04:00
Remove ConDeclGADTPrefixPs
This removes the `ConDeclGADTPrefixPs` per the discussion in #18517.
Most of this patch simply removes code, although the code in the
`rnConDecl` case for `ConDeclGADTPrefixPs` had to be moved around a
bit:
* The nested `forall`s check now lives in the `rnConDecl` case for
`ConDeclGADT`.
* The `LinearTypes`-specific code that used to live in the
`rnConDecl` case for `ConDeclGADTPrefixPs` now lives in
`GHC.Parser.PostProcess.mkGadtDecl`, which is now monadic so that
it can check if `-XLinearTypes` is enabled.
Fixes #18157.
- - - - -
f2d1accf by Leon Schoorl at 2020-08-02T16:44:47-04:00
Fix GHC_STAGE definition generated by make
Fixes #18070
GHC_STAGE is the stage of the compiler we're building, it should be 1,2(,3?).
But make was generating 0 and 1.
Hadrian does this correctly using a similar `+ 1`:
https://gitlab.haskell.org/ghc/ghc/-/blob/eb8115a8c4cbc842b66798480fefc7ab64d31931/hadrian/src/Rules/Generate.hs#L245
- - - - -
c2159000 by Vladislav Zavialov at 2020-08-04T23:10:59+03:00
Grammar for types and data/newtype constructors
Before this patch, we parsed types into a reversed sequence
of operators and operands. For example, (F x y + G a b * X)
would be parsed as [X, *, b, a, G, +, y, x, F],
using a simple grammar:
tyapps
: tyapp
| tyapps tyapp
tyapp
: atype
| PREFIX_AT atype
| tyop
| unpackedness
Then we used a hand-written state machine to assemble this
either into a type, using 'mergeOps',
or into a constructor, using 'mergeDataCon'.
This is due to a syntactic ambiguity:
data T1 a = MkT1 a
data T2 a = Ord a => MkT2 a
In T1, what follows after the = sign is a data/newtype constructor
declaration. However, in T2, what follows is a type (of kind
Constraint). We don't know which of the two we are parsing until we
encounter =>, and we cannot check for => without unlimited lookahead.
This poses a few issues when it comes to e.g. infix operators:
data I1 = Int :+ Bool :+ Char -- bad
data I2 = Int :+ Bool :+ Char => MkI2 -- fine
By this issue alone we are forced into parsing into an intermediate
representation and doing a separate validation pass.
However, should that intermediate representation be as low-level as a
flat sequence of operators and operands?
Before GHC Proposal #229, the answer was Yes, due to some particularly
nasty corner cases:
data T = ! A :+ ! B -- used to be fine, hard to parse
data T = ! A :+ ! B => MkT -- bad
However, now the answer is No, as this corner case is gone:
data T = ! A :+ ! B -- bad
data T = ! A :+ ! B => MkT -- bad
This means we can write a proper grammar for types, overloading it in
the DisambECP style, see Note [Ambiguous syntactic categories].
With this patch, we introduce a new class, DisambTD. Just like
DisambECP is used to disambiguate between expressions, commands, and patterns,
DisambTD is used to disambiguate between types and data/newtype constructors.
This way, we get a proper, declarative grammar for constructors and
types:
infixtype
: ftype
| ftype tyop infixtype
| unpackedness infixtype
ftype
: atype
| tyop
| ftype tyarg
| ftype PREFIX_AT tyarg
tyarg
: atype
| unpackedness atype
And having a grammar for types means we are a step closer to using a
single grammar for types and expressions.
- - - - -
f5ab0e11 by Vladislav Zavialov at 2020-08-05T00:22:36+03:00
Clean up the story around runPV/runECP_P/runECP_PV
This patch started as small documentation change, an attempt to make
Note [Parser-Validator] and Note [Ambiguous syntactic categories]
more clear and up-to-date.
But it turned out that runECP_P/runECP_PV are weakly motivated,
and it's easier to remove them than to find a good rationale/explanation
for their existence.
As the result, we have a bit of refactoring in addition to
documentation update.
- - - - -
30 changed files:
- compiler/GHC/Cmm/CLabel.hs
- compiler/GHC/Cmm/Info.hs
- compiler/GHC/Cmm/Info/Build.hs
- compiler/GHC/Cmm/Pipeline.hs
- compiler/GHC/Cmm/ProcPoint.hs
- compiler/GHC/CmmToAsm.hs
- compiler/GHC/CmmToAsm/Dwarf/Types.hs
- compiler/GHC/CmmToAsm/PIC.hs
- compiler/GHC/CmmToLlvm/Base.hs
- compiler/GHC/Hs/Decls.hs
- compiler/GHC/Hs/Instances.hs
- compiler/GHC/Hs/Type.hs
- compiler/GHC/Hs/Utils.hs
- compiler/GHC/HsToCore.hs
- compiler/GHC/HsToCore/Coverage.hs
- compiler/GHC/Parser.y
- compiler/GHC/Parser/PostProcess.hs
- compiler/GHC/Parser/PostProcess/Haddock.hs
- compiler/GHC/Rename/Module.hs
- compiler/GHC/StgToCmm.hs
- compiler/GHC/StgToCmm/Bind.hs
- compiler/GHC/StgToCmm/Closure.hs
- compiler/GHC/StgToCmm/Heap.hs
- compiler/GHC/StgToCmm/Layout.hs
- compiler/GHC/ThToHs.hs
- includes/ghc.mk
- rts/Hpc.c
- testsuite/tests/haddock/should_compile_flag_haddock/T17544.stderr
- testsuite/tests/haddock/should_compile_flag_haddock/T17544_kw.stderr
- + testsuite/tests/haddock/should_compile_flag_haddock/T17652.hs
The diff was not included because it is too large.
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/734bd8cd1328825ff0c67b1272d0062177eb8583...f5ab0e11eab91fa9262aa377fb09ed004f9a1f26
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/734bd8cd1328825ff0c67b1272d0062177eb8583...f5ab0e11eab91fa9262aa377fb09ed004f9a1f26
You're receiving this email because of your account on gitlab.haskell.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-commits/attachments/20200804/69efbfc5/attachment.html>
More information about the ghc-commits
mailing list