diff options
author | bors[bot] <26634292+bors[bot]@users.noreply.github.com> | 2022-03-06 20:50:55 +0000 |
---|---|---|
committer | GitHub <noreply@github.com> | 2022-03-06 20:50:55 +0000 |
commit | e2bccf43ed1bf33d5f454eab39a7a4a1f115b0bd (patch) | |
tree | 6e9e933267fd6c651c59607668e2fa08641b8b9d /gcc/rust/backend | |
parent | d89c8ccf3237e66029125c0fe007297bb86eca74 (diff) | |
parent | 58d1721529e99c7c633615e7491b777a6198ed00 (diff) | |
download | gcc-e2bccf43ed1bf33d5f454eab39a7a4a1f115b0bd.zip gcc-e2bccf43ed1bf33d5f454eab39a7a4a1f115b0bd.tar.gz gcc-e2bccf43ed1bf33d5f454eab39a7a4a1f115b0bd.tar.bz2 |
Merge #985
985: Parse macro!(); as MacroInvocation with semicolon r=CohenArthur a=CohenArthur
When parsing a macro invocation as a statement, the parser would parse
an expression and then try parsing a semicolon. Since no actual
lookahead was done (which is a good thing), we couldn't convert a
`MacroInvocation` to a `MacroInvocationSemi` after the fact.
Since, unlike function calls, macro invocations can act differently
based on whether or not they are followed by a semicolon, we actually
need to differentiate between the two up until expansion.
This commits adds a new virtual method for ExprWithoutBlock when
converting to ExprStmtWithoutBlock so that classes inheriting
ExprWithoutBlock can specify a new behavior. In the case of our
MacroInvocation class, it simply means toggling a boolean: If we're
converting a macro from an expression to a statement, it must mean that
it should contain a semicolon.
Closes #941
Co-authored-by: Arthur Cohen <arthur.cohen@embecosm.com>
Diffstat (limited to 'gcc/rust/backend')
0 files changed, 0 insertions, 0 deletions