From 98181087984157e27faba0b969e384f3c62c39d5 Mon Sep 17 00:00:00 2001 From: Aleksey Kladov Date: Fri, 31 Jul 2020 20:09:09 +0200 Subject: Rename BindPat -> IdentPat --- crates/ra_ssr/src/parsing.rs | 2 +- crates/ra_ssr/src/resolving.rs | 2 +- crates/ra_ssr/src/tests.rs | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) (limited to 'crates/ra_ssr') 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 { // path refers to semantically the same thing, whereas the non-path-based rules could match // anything. Specifically, if we have a rule like `foo ==>> bar` we only want to match the // `foo` that is in the current scope, not any `foo`. However "foo" can be parsed as a - // pattern (BIND_PAT -> NAME -> IDENT). Allowing such a rule through would result in + // pattern (IDENT_PAT -> NAME -> IDENT). Allowing such a rule through would result in // renaming everything called `foo` to `bar`. It'd also be slow, since without a path, we'd // have to use the slow-scan search mechanism. 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 { return n; } } - SyntaxKind::LET_STMT | SyntaxKind::BIND_PAT => { + SyntaxKind::LET_STMT | SyntaxKind::IDENT_PAT => { if let Some(next) = node.next_sibling() { return pick_node_for_resolution(next); } 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() { fn pattern_is_a_single_segment_path() { mark::check!(pattern_is_a_single_segment_path); // The first function should not be altered because the `foo` in scope at the cursor position is - // a different `foo`. This case is special because "foo" can be parsed as a pattern (BIND_PAT -> + // a different `foo`. This case is special because "foo" can be parsed as a pattern (IDENT_PAT -> // NAME -> IDENT), which contains no path. If we're not careful we'll end up matching the `foo` // in `let foo` from the first function. Whether we should match the `let foo` in the second // function is less clear. At the moment, we don't. Doing so sounds like a rename operation, -- cgit v1.2.3