aboutsummaryrefslogtreecommitdiff
path: root/crates/ra_ssr/src
diff options
context:
space:
mode:
authorbors[bot] <26634292+bors[bot]@users.noreply.github.com>2020-07-31 19:12:38 +0100
committerGitHub <[email protected]>2020-07-31 19:12:38 +0100
commit38ab326aac70484cb951fe9389d788d525d41550 (patch)
tree0032223efeefca76340fb0a97f6f12d0e432a2a9 /crates/ra_ssr/src
parent5cade89d730b025082ff2df70aace259951a9ccf (diff)
parent98181087984157e27faba0b969e384f3c62c39d5 (diff)
Merge #5631
5631: Finalize pattern grammar r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
Diffstat (limited to 'crates/ra_ssr/src')
-rw-r--r--crates/ra_ssr/src/parsing.rs2
-rw-r--r--crates/ra_ssr/src/resolving.rs2
-rw-r--r--crates/ra_ssr/src/tests.rs2
3 files changed, 3 insertions, 3 deletions
diff --git a/crates/ra_ssr/src/parsing.rs b/crates/ra_ssr/src/parsing.rs
index 4e046910c..f455eb5b7 100644
--- a/crates/ra_ssr/src/parsing.rs
+++ b/crates/ra_ssr/src/parsing.rs
@@ -109,7 +109,7 @@ impl RuleBuilder {
109 // path refers to semantically the same thing, whereas the non-path-based rules could match 109 // path refers to semantically the same thing, whereas the non-path-based rules could match
110 // anything. Specifically, if we have a rule like `foo ==>> bar` we only want to match the 110 // anything. Specifically, if we have a rule like `foo ==>> bar` we only want to match the
111 // `foo` that is in the current scope, not any `foo`. However "foo" can be parsed as a 111 // `foo` that is in the current scope, not any `foo`. However "foo" can be parsed as a
112 // pattern (BIND_PAT -> NAME -> IDENT). Allowing such a rule through would result in 112 // pattern (IDENT_PAT -> NAME -> IDENT). Allowing such a rule through would result in
113 // renaming everything called `foo` to `bar`. It'd also be slow, since without a path, we'd 113 // renaming everything called `foo` to `bar`. It'd also be slow, since without a path, we'd
114 // have to use the slow-scan search mechanism. 114 // have to use the slow-scan search mechanism.
115 if self.rules.iter().any(|rule| contains_path(&rule.pattern)) { 115 if self.rules.iter().any(|rule| contains_path(&rule.pattern)) {
diff --git a/crates/ra_ssr/src/resolving.rs b/crates/ra_ssr/src/resolving.rs
index c2fd3b905..6f62000f4 100644
--- a/crates/ra_ssr/src/resolving.rs
+++ b/crates/ra_ssr/src/resolving.rs
@@ -198,7 +198,7 @@ fn pick_node_for_resolution(node: SyntaxNode) -> SyntaxNode {
198 return n; 198 return n;
199 } 199 }
200 } 200 }
201 SyntaxKind::LET_STMT | SyntaxKind::BIND_PAT => { 201 SyntaxKind::LET_STMT | SyntaxKind::IDENT_PAT => {
202 if let Some(next) = node.next_sibling() { 202 if let Some(next) = node.next_sibling() {
203 return pick_node_for_resolution(next); 203 return pick_node_for_resolution(next);
204 } 204 }
diff --git a/crates/ra_ssr/src/tests.rs b/crates/ra_ssr/src/tests.rs
index a4fa2cb44..2ae03c64c 100644
--- a/crates/ra_ssr/src/tests.rs
+++ b/crates/ra_ssr/src/tests.rs
@@ -924,7 +924,7 @@ fn ufcs_matches_method_call() {
924fn pattern_is_a_single_segment_path() { 924fn pattern_is_a_single_segment_path() {
925 mark::check!(pattern_is_a_single_segment_path); 925 mark::check!(pattern_is_a_single_segment_path);
926 // The first function should not be altered because the `foo` in scope at the cursor position is 926 // The first function should not be altered because the `foo` in scope at the cursor position is
927 // a different `foo`. This case is special because "foo" can be parsed as a pattern (BIND_PAT -> 927 // a different `foo`. This case is special because "foo" can be parsed as a pattern (IDENT_PAT ->
928 // NAME -> IDENT), which contains no path. If we're not careful we'll end up matching the `foo` 928 // NAME -> IDENT), which contains no path. If we're not careful we'll end up matching the `foo`
929 // in `let foo` from the first function. Whether we should match the `let foo` in the second 929 // in `let foo` from the first function. Whether we should match the `let foo` in the second
930 // function is less clear. At the moment, we don't. Doing so sounds like a rename operation, 930 // function is less clear. At the moment, we don't. Doing so sounds like a rename operation,