bors[bot] ac123ac9e4 Merge #6587 ... 6587: SSR: Support statement matching and replacing r=davidlattimore a=MarijnS95 For #3186 Hi! This is a smaller initial patchset that came up while working on support for statement lists (and my first time working on RA 😁). It has me stuck on trailing semicolons for which I hope to receive some feedback. Matching (and replacing) `let` bindings with a trailing semicolon works fine, but trying to omit these (to make patterns more ergonomic) turns out more complex than expected. The "optional trailing semicolon solution" implemented in this PR is ugly because `Matcher::attempt_match_token` should only consume a trailing `;` when parsing `let` bindings to prevent other code from breaking. That at the same time has a nasty side-effect of `;` ending up in the matched code: any replacements on that should include the trailing semicolon as well even if it was not in the pattern. A better example is in the tests: 3ae1649c24/crates/ssr/src/tests.rs (L178-L184) The end result to achieve is (I guess) allowing replacement of let bindings without trailing semicolon like `let x = $a ==>> let x = 1` (but including them on both sides is still fine), and should make replacement in a macro call (where `foo!(let a = 2;)` for a `$x:stmt` is invalid syntax) possible as well. That should allow to enable/fix these tests: 3ae1649c24/crates/ssr/src/tests.rs (L201-L214) A possible MVP of this PR might be to drop this optional `;' handling entirely and only allow an SSR pattern/template with semicolons on either side. Co-authored-by: Marijn Suijten <marijn@traverseresearch.nl>		2021-01-04 11:14:40 +00:00
..
fuzz
src	parser,syntax: Add separate parser for stmt with optional semicolon	2021-01-03 12:05:52 +01:00
test_data	parser,syntax: Add separate parser for stmt with optional semicolon	2021-01-03 12:05:52 +01:00
Cargo.toml	Upgrade expect-test to 1.1	2021-01-03 14:43:29 +01:00