2018-02-17 16:06:48 -06:00
|
|
|
use super::*;
|
|
|
|
|
2019-01-18 02:02:30 -06:00
|
|
|
pub(super) const PATTERN_FIRST: TokenSet = expressions::LITERAL_FIRST
|
|
|
|
.union(paths::PATH_FIRST)
|
|
|
|
.union(token_set![
|
|
|
|
REF_KW, MUT_KW, L_PAREN, L_BRACK, AMP, UNDERSCORE
|
|
|
|
]);
|
2018-08-24 12:50:37 -05:00
|
|
|
|
2018-02-17 16:06:48 -06:00
|
|
|
pub(super) fn pattern(p: &mut Parser) {
|
Fix yet another parser infinite loop
This commit is an example of fixing a common parser error: infinite
loop due to error recovery.
This error typically happens when we parse a list of items and fail to
parse a specific item at the current position.
One choices is to skip a token and try to parse a list item at the
next position. This is a good, but not universal, default. When
parsing a list of arguments in a function call, you, for example,
don't want to skip over `fn`, because it's most likely that it is a
function declaration, and not a mistyped arg:
```
fn foo() {
quux(1, 2
fn bar() {
}
```
Another choice is to bail out of the loop immediately, but it isn't
perfect either: sometimes skipping over garbage helps:
```
quux(1, foo:, 92) // should skip over `:`, b/c that's part of `foo::bar`
```
In general, parser tries to balance these two cases, though we don't
have a definitive strategy yet.
However, if the parser accidentally neither skips over a token, nor
breaks out of the loop, then it becomes stuck in the loop infinitely
(there's an internal counter to self-check this situation and panic
though), and that's exactly what is demonstrated by the test.
To fix such situation, first of all, add the test case to tests/data/parser/{err,fuzz-failures}.
Then, run
```
RUST_BACKTRACE=short cargo test --package libsyntax2
````
to verify that parser indeed panics, and to get an idea what grammar
production is the culprit (look for `_list` functions!).
In this case, I see
```
10: libsyntax2::grammar::expressions::atom::match_arm_list
at crates/libsyntax2/src/grammar/expressions/atom.rs:309
```
and that's look like it might be a culprit. I verify it by adding
`eprintln!("loopy {:?}", p.current());` and indeed I see that this is
printed repeatedly.
Diagnosing this a bit shows that the problem is that
`pattern::pattern` function does not consume anything if the next
token is `let`. That is a good default to make cases like
```
let
let foo = 92;
```
where the user hasn't typed the pattern yet, to parse in a reasonable
they correctly.
For match arms, pretty much the single thing we expect is a pattern,
so, for a fix, I introduce a special variant of pattern that does not
do recovery.
2018-09-08 11:10:20 -05:00
|
|
|
pattern_r(p, PAT_RECOVERY_SET)
|
|
|
|
}
|
|
|
|
|
|
|
|
pub(super) fn pattern_r(p: &mut Parser, recovery_set: TokenSet) {
|
|
|
|
if let Some(lhs) = atom_pat(p, recovery_set) {
|
2018-08-08 07:05:33 -05:00
|
|
|
// test range_pat
|
|
|
|
// fn main() {
|
2018-12-17 16:34:18 -06:00
|
|
|
// match 92 {
|
|
|
|
// 0 ... 100 => (),
|
|
|
|
// 101 ..= 200 => (),
|
|
|
|
// 200 .. 301=> (),
|
|
|
|
// }
|
2018-08-08 07:05:33 -05:00
|
|
|
// }
|
2018-12-17 16:34:18 -06:00
|
|
|
if p.at(DOTDOTDOT) || p.at(DOTDOTEQ) || p.at(DOTDOT) {
|
2018-08-08 07:05:33 -05:00
|
|
|
let m = lhs.precede(p);
|
|
|
|
p.bump();
|
Fix yet another parser infinite loop
This commit is an example of fixing a common parser error: infinite
loop due to error recovery.
This error typically happens when we parse a list of items and fail to
parse a specific item at the current position.
One choices is to skip a token and try to parse a list item at the
next position. This is a good, but not universal, default. When
parsing a list of arguments in a function call, you, for example,
don't want to skip over `fn`, because it's most likely that it is a
function declaration, and not a mistyped arg:
```
fn foo() {
quux(1, 2
fn bar() {
}
```
Another choice is to bail out of the loop immediately, but it isn't
perfect either: sometimes skipping over garbage helps:
```
quux(1, foo:, 92) // should skip over `:`, b/c that's part of `foo::bar`
```
In general, parser tries to balance these two cases, though we don't
have a definitive strategy yet.
However, if the parser accidentally neither skips over a token, nor
breaks out of the loop, then it becomes stuck in the loop infinitely
(there's an internal counter to self-check this situation and panic
though), and that's exactly what is demonstrated by the test.
To fix such situation, first of all, add the test case to tests/data/parser/{err,fuzz-failures}.
Then, run
```
RUST_BACKTRACE=short cargo test --package libsyntax2
````
to verify that parser indeed panics, and to get an idea what grammar
production is the culprit (look for `_list` functions!).
In this case, I see
```
10: libsyntax2::grammar::expressions::atom::match_arm_list
at crates/libsyntax2/src/grammar/expressions/atom.rs:309
```
and that's look like it might be a culprit. I verify it by adding
`eprintln!("loopy {:?}", p.current());` and indeed I see that this is
printed repeatedly.
Diagnosing this a bit shows that the problem is that
`pattern::pattern` function does not consume anything if the next
token is `let`. That is a good default to make cases like
```
let
let foo = 92;
```
where the user hasn't typed the pattern yet, to parse in a reasonable
they correctly.
For match arms, pretty much the single thing we expect is a pattern,
so, for a fix, I introduce a special variant of pattern that does not
do recovery.
2018-09-08 11:10:20 -05:00
|
|
|
atom_pat(p, recovery_set);
|
2018-08-08 07:05:33 -05:00
|
|
|
m.complete(p, RANGE_PAT);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-08-28 11:35:09 -05:00
|
|
|
const PAT_RECOVERY_SET: TokenSet =
|
2018-09-03 07:10:06 -05:00
|
|
|
token_set![LET_KW, IF_KW, WHILE_KW, LOOP_KW, MATCH_KW, R_PAREN, COMMA];
|
2018-08-28 11:35:09 -05:00
|
|
|
|
Fix yet another parser infinite loop
This commit is an example of fixing a common parser error: infinite
loop due to error recovery.
This error typically happens when we parse a list of items and fail to
parse a specific item at the current position.
One choices is to skip a token and try to parse a list item at the
next position. This is a good, but not universal, default. When
parsing a list of arguments in a function call, you, for example,
don't want to skip over `fn`, because it's most likely that it is a
function declaration, and not a mistyped arg:
```
fn foo() {
quux(1, 2
fn bar() {
}
```
Another choice is to bail out of the loop immediately, but it isn't
perfect either: sometimes skipping over garbage helps:
```
quux(1, foo:, 92) // should skip over `:`, b/c that's part of `foo::bar`
```
In general, parser tries to balance these two cases, though we don't
have a definitive strategy yet.
However, if the parser accidentally neither skips over a token, nor
breaks out of the loop, then it becomes stuck in the loop infinitely
(there's an internal counter to self-check this situation and panic
though), and that's exactly what is demonstrated by the test.
To fix such situation, first of all, add the test case to tests/data/parser/{err,fuzz-failures}.
Then, run
```
RUST_BACKTRACE=short cargo test --package libsyntax2
````
to verify that parser indeed panics, and to get an idea what grammar
production is the culprit (look for `_list` functions!).
In this case, I see
```
10: libsyntax2::grammar::expressions::atom::match_arm_list
at crates/libsyntax2/src/grammar/expressions/atom.rs:309
```
and that's look like it might be a culprit. I verify it by adding
`eprintln!("loopy {:?}", p.current());` and indeed I see that this is
printed repeatedly.
Diagnosing this a bit shows that the problem is that
`pattern::pattern` function does not consume anything if the next
token is `let`. That is a good default to make cases like
```
let
let foo = 92;
```
where the user hasn't typed the pattern yet, to parse in a reasonable
they correctly.
For match arms, pretty much the single thing we expect is a pattern,
so, for a fix, I introduce a special variant of pattern that does not
do recovery.
2018-09-08 11:10:20 -05:00
|
|
|
fn atom_pat(p: &mut Parser, recovery_set: TokenSet) -> Option<CompletedMarker> {
|
2018-08-04 07:47:45 -05:00
|
|
|
let la0 = p.nth(0);
|
|
|
|
let la1 = p.nth(1);
|
2018-10-15 16:44:23 -05:00
|
|
|
if la0 == REF_KW
|
|
|
|
|| la0 == MUT_KW
|
|
|
|
|| (la0 == IDENT && !(la1 == COLONCOLON || la1 == L_PAREN || la1 == L_CURLY))
|
|
|
|
{
|
2018-08-08 07:05:33 -05:00
|
|
|
return Some(bind_pat(p, true));
|
2018-08-04 07:47:45 -05:00
|
|
|
}
|
|
|
|
if paths::is_path_start(p) {
|
2018-08-08 07:05:33 -05:00
|
|
|
return Some(path_pat(p));
|
2018-08-04 07:47:45 -05:00
|
|
|
}
|
|
|
|
|
2018-08-07 16:59:16 -05:00
|
|
|
// test literal_pattern
|
|
|
|
// fn main() {
|
|
|
|
// match () {
|
2018-12-30 07:51:40 -06:00
|
|
|
// -1 => (),
|
2018-08-07 16:59:16 -05:00
|
|
|
// 92 => (),
|
|
|
|
// 'c' => (),
|
|
|
|
// "hello" => (),
|
|
|
|
// }
|
|
|
|
// }
|
2018-12-30 07:51:40 -06:00
|
|
|
if p.at(MINUS) && (p.nth(1) == INT_NUMBER || p.nth(1) == FLOAT_NUMBER) {
|
|
|
|
p.bump();
|
|
|
|
}
|
|
|
|
|
2018-10-16 10:51:58 -05:00
|
|
|
if let Some(m) = expressions::literal(p) {
|
|
|
|
return Some(m);
|
2018-08-07 16:59:16 -05:00
|
|
|
}
|
|
|
|
|
2018-08-08 07:05:33 -05:00
|
|
|
let m = match la0 {
|
2018-02-17 16:06:48 -06:00
|
|
|
UNDERSCORE => placeholder_pat(p),
|
2018-08-05 10:18:02 -05:00
|
|
|
AMP => ref_pat(p),
|
2018-08-07 06:41:03 -05:00
|
|
|
L_PAREN => tuple_pat(p),
|
2018-08-07 09:00:45 -05:00
|
|
|
L_BRACK => slice_pat(p),
|
2018-08-08 07:05:33 -05:00
|
|
|
_ => {
|
Fix yet another parser infinite loop
This commit is an example of fixing a common parser error: infinite
loop due to error recovery.
This error typically happens when we parse a list of items and fail to
parse a specific item at the current position.
One choices is to skip a token and try to parse a list item at the
next position. This is a good, but not universal, default. When
parsing a list of arguments in a function call, you, for example,
don't want to skip over `fn`, because it's most likely that it is a
function declaration, and not a mistyped arg:
```
fn foo() {
quux(1, 2
fn bar() {
}
```
Another choice is to bail out of the loop immediately, but it isn't
perfect either: sometimes skipping over garbage helps:
```
quux(1, foo:, 92) // should skip over `:`, b/c that's part of `foo::bar`
```
In general, parser tries to balance these two cases, though we don't
have a definitive strategy yet.
However, if the parser accidentally neither skips over a token, nor
breaks out of the loop, then it becomes stuck in the loop infinitely
(there's an internal counter to self-check this situation and panic
though), and that's exactly what is demonstrated by the test.
To fix such situation, first of all, add the test case to tests/data/parser/{err,fuzz-failures}.
Then, run
```
RUST_BACKTRACE=short cargo test --package libsyntax2
````
to verify that parser indeed panics, and to get an idea what grammar
production is the culprit (look for `_list` functions!).
In this case, I see
```
10: libsyntax2::grammar::expressions::atom::match_arm_list
at crates/libsyntax2/src/grammar/expressions/atom.rs:309
```
and that's look like it might be a culprit. I verify it by adding
`eprintln!("loopy {:?}", p.current());` and indeed I see that this is
printed repeatedly.
Diagnosing this a bit shows that the problem is that
`pattern::pattern` function does not consume anything if the next
token is `let`. That is a good default to make cases like
```
let
let foo = 92;
```
where the user hasn't typed the pattern yet, to parse in a reasonable
they correctly.
For match arms, pretty much the single thing we expect is a pattern,
so, for a fix, I introduce a special variant of pattern that does not
do recovery.
2018-09-08 11:10:20 -05:00
|
|
|
p.err_recover("expected pattern", recovery_set);
|
2018-08-08 07:05:33 -05:00
|
|
|
return None;
|
|
|
|
}
|
|
|
|
};
|
|
|
|
Some(m)
|
2018-02-17 16:06:48 -06:00
|
|
|
}
|
|
|
|
|
2018-08-04 07:47:45 -05:00
|
|
|
// test path_part
|
|
|
|
// fn foo() {
|
|
|
|
// let foo::Bar = ();
|
|
|
|
// let ::Bar = ();
|
|
|
|
// let Bar { .. } = ();
|
|
|
|
// let Bar(..) = ();
|
|
|
|
// }
|
2018-08-08 07:05:33 -05:00
|
|
|
fn path_pat(p: &mut Parser) -> CompletedMarker {
|
2018-08-13 10:23:14 -05:00
|
|
|
assert!(paths::is_path_start(p));
|
2018-08-04 07:47:45 -05:00
|
|
|
let m = p.start();
|
|
|
|
paths::expr_path(p);
|
|
|
|
let kind = match p.current() {
|
|
|
|
L_PAREN => {
|
|
|
|
tuple_pat_fields(p);
|
2018-08-07 06:41:03 -05:00
|
|
|
TUPLE_STRUCT_PAT
|
2018-08-04 07:47:45 -05:00
|
|
|
}
|
|
|
|
L_CURLY => {
|
2018-08-24 11:27:30 -05:00
|
|
|
field_pat_list(p);
|
2018-08-04 07:47:45 -05:00
|
|
|
STRUCT_PAT
|
|
|
|
}
|
2018-10-15 16:44:23 -05:00
|
|
|
_ => PATH_PAT,
|
2018-08-04 07:47:45 -05:00
|
|
|
};
|
2018-08-08 07:05:33 -05:00
|
|
|
m.complete(p, kind)
|
2018-08-04 07:47:45 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
// test tuple_pat_fields
|
|
|
|
// fn foo() {
|
|
|
|
// let S() = ();
|
|
|
|
// let S(_) = ();
|
|
|
|
// let S(_,) = ();
|
|
|
|
// let S(_, .. , x) = ();
|
|
|
|
// }
|
|
|
|
fn tuple_pat_fields(p: &mut Parser) {
|
|
|
|
assert!(p.at(L_PAREN));
|
|
|
|
p.bump();
|
2018-09-12 03:26:52 -05:00
|
|
|
pat_list(p, R_PAREN);
|
2018-08-04 07:47:45 -05:00
|
|
|
p.expect(R_PAREN);
|
|
|
|
}
|
|
|
|
|
2018-08-24 11:27:30 -05:00
|
|
|
// test field_pat_list
|
2018-08-04 07:47:45 -05:00
|
|
|
// fn foo() {
|
|
|
|
// let S {} = ();
|
|
|
|
// let S { f, ref mut g } = ();
|
|
|
|
// let S { h: _, ..} = ();
|
|
|
|
// let S { h: _, } = ();
|
|
|
|
// }
|
2018-08-24 11:27:30 -05:00
|
|
|
fn field_pat_list(p: &mut Parser) {
|
2018-08-04 07:47:45 -05:00
|
|
|
assert!(p.at(L_CURLY));
|
2018-08-24 11:27:30 -05:00
|
|
|
let m = p.start();
|
2018-08-04 07:47:45 -05:00
|
|
|
p.bump();
|
|
|
|
while !p.at(EOF) && !p.at(R_CURLY) {
|
|
|
|
match p.current() {
|
|
|
|
DOTDOT => p.bump(),
|
2019-01-18 18:02:38 -06:00
|
|
|
IDENT if p.nth(1) == COLON => field_pat(p),
|
|
|
|
L_CURLY => error_block(p, "expected ident"),
|
|
|
|
_ => {
|
|
|
|
bind_pat(p, false);
|
|
|
|
}
|
2018-08-04 07:47:45 -05:00
|
|
|
}
|
|
|
|
if !p.at(R_CURLY) {
|
|
|
|
p.expect(COMMA);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
p.expect(R_CURLY);
|
2018-08-24 11:27:30 -05:00
|
|
|
m.complete(p, FIELD_PAT_LIST);
|
2018-08-04 07:47:45 -05:00
|
|
|
}
|
|
|
|
|
2019-01-18 07:52:31 -06:00
|
|
|
fn field_pat(p: &mut Parser) {
|
2019-01-18 18:02:38 -06:00
|
|
|
assert!(p.at(IDENT));
|
|
|
|
assert!(p.nth(1) == COLON);
|
|
|
|
|
2019-01-18 07:52:31 -06:00
|
|
|
let m = p.start();
|
2019-01-18 18:02:38 -06:00
|
|
|
name(p);
|
|
|
|
p.bump();
|
|
|
|
pattern(p);
|
2019-01-18 07:52:31 -06:00
|
|
|
m.complete(p, FIELD_PAT);
|
|
|
|
}
|
|
|
|
|
2018-02-17 16:06:48 -06:00
|
|
|
// test placeholder_pat
|
|
|
|
// fn main() { let _ = (); }
|
2018-08-08 07:05:33 -05:00
|
|
|
fn placeholder_pat(p: &mut Parser) -> CompletedMarker {
|
2018-02-17 16:06:48 -06:00
|
|
|
assert!(p.at(UNDERSCORE));
|
|
|
|
let m = p.start();
|
|
|
|
p.bump();
|
2018-08-08 07:05:33 -05:00
|
|
|
m.complete(p, PLACEHOLDER_PAT)
|
2018-02-17 16:06:48 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
// test ref_pat
|
|
|
|
// fn main() {
|
|
|
|
// let &a = ();
|
|
|
|
// let &mut b = ();
|
|
|
|
// }
|
2018-08-08 07:05:33 -05:00
|
|
|
fn ref_pat(p: &mut Parser) -> CompletedMarker {
|
2018-08-05 10:18:02 -05:00
|
|
|
assert!(p.at(AMP));
|
2018-02-17 16:06:48 -06:00
|
|
|
let m = p.start();
|
|
|
|
p.bump();
|
|
|
|
p.eat(MUT_KW);
|
|
|
|
pattern(p);
|
2018-08-08 07:05:33 -05:00
|
|
|
m.complete(p, REF_PAT)
|
2018-02-17 16:06:48 -06:00
|
|
|
}
|
|
|
|
|
2018-08-07 06:41:03 -05:00
|
|
|
// test tuple_pat
|
|
|
|
// fn main() {
|
|
|
|
// let (a, b, ..) = ();
|
|
|
|
// }
|
2018-08-08 07:05:33 -05:00
|
|
|
fn tuple_pat(p: &mut Parser) -> CompletedMarker {
|
2018-08-07 06:41:03 -05:00
|
|
|
assert!(p.at(L_PAREN));
|
|
|
|
let m = p.start();
|
|
|
|
tuple_pat_fields(p);
|
2018-08-08 07:05:33 -05:00
|
|
|
m.complete(p, TUPLE_PAT)
|
2018-08-07 06:41:03 -05:00
|
|
|
}
|
|
|
|
|
2018-08-07 09:00:45 -05:00
|
|
|
// test slice_pat
|
|
|
|
// fn main() {
|
|
|
|
// let [a, b, ..] = [];
|
|
|
|
// }
|
2018-08-08 07:05:33 -05:00
|
|
|
fn slice_pat(p: &mut Parser) -> CompletedMarker {
|
2018-08-07 09:00:45 -05:00
|
|
|
assert!(p.at(L_BRACK));
|
|
|
|
let m = p.start();
|
|
|
|
p.bump();
|
2018-09-12 03:26:52 -05:00
|
|
|
pat_list(p, R_BRACK);
|
|
|
|
p.expect(R_BRACK);
|
|
|
|
m.complete(p, SLICE_PAT)
|
|
|
|
}
|
|
|
|
|
|
|
|
fn pat_list(p: &mut Parser, ket: SyntaxKind) {
|
|
|
|
while !p.at(EOF) && !p.at(ket) {
|
2018-08-07 09:00:45 -05:00
|
|
|
match p.current() {
|
|
|
|
DOTDOT => p.bump(),
|
2018-09-12 03:26:52 -05:00
|
|
|
_ => {
|
|
|
|
if !p.at_ts(PATTERN_FIRST) {
|
|
|
|
p.error("expected a pattern");
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
pattern(p)
|
2018-10-15 16:44:23 -05:00
|
|
|
}
|
2018-08-07 09:00:45 -05:00
|
|
|
}
|
2018-09-12 03:26:52 -05:00
|
|
|
if !p.at(ket) {
|
2018-08-07 09:00:45 -05:00
|
|
|
p.expect(COMMA);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-02-17 16:06:48 -06:00
|
|
|
// test bind_pat
|
|
|
|
// fn main() {
|
|
|
|
// let a = ();
|
2018-07-31 07:30:11 -05:00
|
|
|
// let mut b = ();
|
|
|
|
// let ref c = ();
|
|
|
|
// let ref mut d = ();
|
|
|
|
// let e @ _ = ();
|
|
|
|
// let ref mut f @ g @ _ = ();
|
2018-02-17 16:06:48 -06:00
|
|
|
// }
|
2018-08-08 07:05:33 -05:00
|
|
|
fn bind_pat(p: &mut Parser, with_at: bool) -> CompletedMarker {
|
2018-02-17 16:06:48 -06:00
|
|
|
let m = p.start();
|
2018-07-31 07:40:40 -05:00
|
|
|
p.eat(REF_KW);
|
|
|
|
p.eat(MUT_KW);
|
2018-02-17 16:06:48 -06:00
|
|
|
name(p);
|
2018-08-04 07:47:45 -05:00
|
|
|
if with_at && p.eat(AT) {
|
2018-02-17 16:06:48 -06:00
|
|
|
pattern(p);
|
|
|
|
}
|
2018-08-08 07:05:33 -05:00
|
|
|
m.complete(p, BIND_PAT)
|
2018-02-17 16:06:48 -06:00
|
|
|
}
|