Rename BindPat -> IdentPat

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 {
         // 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,