diff options
author | bors[bot] <26634292+bors[bot]@users.noreply.github.com> | 2022-03-23 09:28:09 +0000 |
---|---|---|
committer | GitHub <noreply@github.com> | 2022-03-23 09:28:09 +0000 |
commit | eef1ee2638c73e35cc804c2d4ab42598dccea8ac (patch) | |
tree | 49e8cb28376b9059702bad0b2ead1fa054ad583b /gcc/rust/parse/rust-parse.cc | |
parent | b9720caa100efa6758a5f0d54d3764072d83be41 (diff) | |
parent | ef5638186202daac03feed7a20eb975991965403 (diff) | |
download | gcc-eef1ee2638c73e35cc804c2d4ab42598dccea8ac.zip gcc-eef1ee2638c73e35cc804c2d4ab42598dccea8ac.tar.gz gcc-eef1ee2638c73e35cc804c2d4ab42598dccea8ac.tar.bz2 |
Merge #1049
1049: Add better restrictions around semicolons in statements r=CohenArthur a=CohenArthur
When parsing macro invocations, rustc does not actually consume the
statement's trailing semicolon.
Let's take the following example:
```rust
macro_rules! one_stmt {
($s:stmt) => {};
}
macro_rules! one_or_more_stmt {
($($s:stmt)*) => {};
}
one_stmt!(let a = 1);
one_stmt!(let b = 2;); // error
one_or_more_stmt!(;); // valid
one_or_more_stmt!(let a = 15;); // valid, two statements!
one_or_more_stmt!(let a = 15 let b = 13); // valid, two statements again
```
A semicolon can count as a valid empty statement, but cannot be part of
a statement (in macro invocations). This commit adds more restrictions
that allow the parser to not always expect a semicolon token after the
statement. Furthermore, this fixes a test that was previously accepted
by the compiler but not by rustc.
Fixes #1046
Co-authored-by: Arthur Cohen <arthur.cohen@embecosm.com>
Diffstat (limited to 'gcc/rust/parse/rust-parse.cc')
0 files changed, 0 insertions, 0 deletions