No description
Find a file
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
.cargo Use lld on winsows 2020-08-19 20:17:49 +02:00
.github Use stable instead of beta on macos-11 release runner 2021-01-01 09:44:01 +02:00
.vscode vscode client side tests 2020-05-20 22:31:39 +03:00
assets Add SVG logos to assets directory 2020-08-28 21:41:45 +10:00
crates Merge #6587 2021-01-04 11:14:40 +00:00
docs Merge #7113 2021-01-03 18:22:07 +00:00
editors/code Merge #7068 2021-01-03 09:03:15 +00:00
xtask Stop using beta toolchain in xtask dist 2021-01-02 09:51:41 +02:00
.gitattributes Rename ra_syntax -> syntax 2020-08-12 18:30:53 +02:00
.gitignore add open Cargo.toml action 2020-11-12 17:48:07 -08:00
bors.toml Reduce bors timeout 2020-10-14 13:37:20 +02:00
Cargo.lock Upgrade expect-test to 1.1 2021-01-03 14:43:29 +01:00
Cargo.toml Remove local ungrammar dependency 2020-12-23 11:22:36 +01:00
LICENSE-APACHE Licenses 2018-01-10 22:47:04 +03:00
LICENSE-MIT Licenses 2018-01-10 22:47:04 +03:00
PRIVACY.md Add notes concerning privacy and network access 2020-10-04 20:16:53 +03:00
README.md Replace logo in readme with SVG version 2020-08-28 21:42:12 +10:00
rustfmt.toml Remove forcing \n via rustfmt 2019-11-02 22:19:59 +03:00

rust-analyzer logo

rust-analyzer is an experimental modular compiler frontend for the Rust language. It is a part of a larger rls-2.0 effort to create excellent IDE support for Rust.

Work on rust-analyzer is sponsored by

Ferrous Systems

Quick Start

https://rust-analyzer.github.io/manual.html#installation

Documentation

If you want to contribute to rust-analyzer or are just curious about how things work under the hood, check the ./docs/dev folder.

If you want to use rust-analyzer's language server with your editor of choice, check the manual folder. It also contains some tips & tricks to help you be more productive when using rust-analyzer.

Communication

For usage and troubleshooting requests, please use "IDEs and Editors" category of the Rust forum:

https://users.rust-lang.org/c/ide/14

For questions about development and implementation, join rls-2.0 working group on Zulip:

https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frls-2.2E0

License

Rust analyzer is primarily distributed under the terms of both the MIT license and the Apache License (Version 2.0).

See LICENSE-APACHE and LICENSE-MIT for details.