[Git][ghc/ghc][wip/marge_bot_batch_merge_job] 14 commits: Grammar for types and data/newtype constructors
Marge Bot
gitlab at gitlab.haskell.org
Fri Aug 7 06:24:42 UTC 2020
Marge Bot pushed to branch wip/marge_bot_batch_merge_job at Glasgow Haskell Compiler / GHC
Commits:
686e06c5 by Vladislav Zavialov at 2020-08-06T13:34:05-04: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.
- - - - -
6770e199 by Vladislav Zavialov at 2020-08-06T13:34:05-04:00
Clean up the story around runPV/runECP_P/runECP_PV
This patch started as a 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, there's a bit of refactoring in addition to
a documentation update.
- - - - -
826d07db by Vladislav Zavialov at 2020-08-06T13:34:06-04:00
Fix debug_ppr_ty ForAllTy (#18522)
Before this change, GHC would
pretty-print forall k. forall a -> ()
as forall @k a. ()
which isn't even valid Haskell.
- - - - -
0ddb4384 by Vladislav Zavialov at 2020-08-06T13:34:06-04:00
Fix visible forall in ppr_ty (#18522)
Before this patch, this type:
T :: forall k -> (k ~ k) => forall j -> k -> j -> Type
was printed incorrectly as:
T :: forall k j -> (k ~ k) => k -> j -> Type
- - - - -
d2a43225 by Richard Eisenberg at 2020-08-06T13:34:06-04:00
Fail eagerly on a lev-poly datacon arg
Close #18534.
See commentary in the patch.
- - - - -
63348155 by Sylvain Henry at 2020-08-06T13:34:08-04:00
Use a type alias for Ways
- - - - -
9570c212 by Takenobu Tani at 2020-08-06T19:46:46-04:00
users-guide: Rename 8.12 to 9.0
GHC 8.12.1 has been renamed to GHC 9.0.1.
See also:
https://mail.haskell.org/pipermail/ghc-devs/2020-July/019083.html
[skip ci]
- - - - -
786ca395 by Cale Gibbard at 2020-08-07T02:24:39-04:00
A fix to an error message in monad comprehensions, and a move of dsHandleMonadicFailure
as suggested by comments on !2330.
- - - - -
758cb7a2 by Cale Gibbard at 2020-08-07T02:24:39-04:00
Add some tests for fail messages in do-expressions and monad-comprehensions.
- - - - -
1e242fd8 by Ben Gamari at 2020-08-07T02:24:39-04:00
cmm: Clean up Notes a bit
- - - - -
c3ce0089 by Ben Gamari at 2020-08-07T02:24:39-04:00
CmmLint: Check foreign call argument register invariant
As mentioned in Note [Register parameter passing] the arguments of
foreign calls cannot refer to caller-saved registers.
- - - - -
8e48ae7b by Ben Gamari at 2020-08-07T02:24:39-04:00
nativeGen: One approach to fix #18527
Previously the code generator could produce corrupt C call sequences due
to register overlap between MachOp lowerings and the platform's calling
convention. We fix this using a hack described in Note [Evaluate C-call
arguments before placing in destination registers].
- - - - -
2891a91d by Ben Gamari at 2020-08-07T02:24:39-04:00
testsuite: Add test for #18527
- - - - -
2edc326e by Ben Gamari at 2020-08-07T02:24:39-04:00
testsuite: Fix prog001
Previously it failed as the `ghc` package was not visible.
- - - - -
30 changed files:
- compiler/GHC/Cmm/Lint.hs
- compiler/GHC/Cmm/MachOp.hs
- compiler/GHC/Cmm/Node.hs
- compiler/GHC/Cmm/Sink.hs
- compiler/GHC/CmmToAsm/X86/CodeGen.hs
- compiler/GHC/Core/TyCo/Ppr.hs
- compiler/GHC/Driver/Session.hs
- compiler/GHC/HsToCore/Expr.hs
- compiler/GHC/HsToCore/Expr.hs-boot
- compiler/GHC/HsToCore/ListComp.hs
- compiler/GHC/HsToCore/Utils.hs
- compiler/GHC/Iface/Type.hs
- compiler/GHC/Parser.y
- compiler/GHC/Parser/PostProcess.hs
- compiler/GHC/Platform/Profile.hs
- compiler/GHC/Platform/Ways.hs
- compiler/GHC/StgToCmm/Foreign.hs
- compiler/GHC/StgToCmm/Utils.hs
- compiler/GHC/Tc/TyCl.hs
- compiler/GHC/Unit/State.hs
- docs/users_guide/8.12.1-notes.rst → docs/users_guide/9.0.1-notes.rst
- docs/users_guide/exts/lambda_case.rst
- docs/users_guide/exts/lexical_negation.rst
- docs/users_guide/exts/linear_types.rst
- docs/users_guide/exts/negative_literals.rst
- docs/users_guide/exts/qualified_do.rst
- docs/users_guide/release-notes.rst
- docs/users_guide/using-warnings.rst
- includes/stg/MachRegs.h
- + testsuite/tests/codeGen/should_run/T18527.hs
The diff was not included because it is too large.
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/1aff3f9692f4a0c7754ca00aa0ff07ba8659b1c3...2edc326efadb1d9cb9e412ecbee47cc9bf3d9b31
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/1aff3f9692f4a0c7754ca00aa0ff07ba8659b1c3...2edc326efadb1d9cb9e412ecbee47cc9bf3d9b31
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/20200807/48a077d3/attachment.html>
More information about the ghc-commits
mailing list