fix(ide-completion): fix handling of for in impl T for A in function body

[rami3l]

Closes #17787.

[rami3l]

The couple of failed tests I checked seem fine, they need a baseline update.

@lnicola Thanks! The fix per se looks good to me, but I wonder if this is in line with other stuff, such as:

rust-analyzer/crates/ide-completion/src/tests/special.rs

Lines 1266 to 1299 in 13ac53e

	#[test]
	fn completes_flyimport_with_doc_alias_in_another_mod() {
	check(
	r#"
	mod foo {
	#[doc(alias = "Qux")]
	pub struct Bar();
	}
	fn here_we_go() {
	let foo = Bar$0
	}
	"#,
	expect![[r#"
	fn here_we_go() fn()
	md foo
	st Bar (alias Qux) (use foo::Bar) Bar
	bt u32 u32
	kw crate::
	kw false
	kw for
	kw if
	kw if let
	kw loop
	kw match
	kw return
	kw self::
	kw true
	kw unsafe
	kw while
	kw while let
	"#]],
	);
	}

Do we really need all those suggestions? This PR eliminates for which seems reasonable to me, but what about other stuff like loop and match? Maybe in_block_expr is not the correct predicate here?

[rami3l]

@lnicola The key issue here seems to be that impl T for A is local to the function, otherwise I cannot reproduce #17787. I'll try finding a smarter way of doing things, and adding a test case if possible.

[Veykril]

We incorrectly land in a PathKind::Expr here in completion analysis likely due to parser recovery

[Veykril]

Given

fn foo() {
    struct X;
    impl X fo { }
}

we get a

[email protected]
  [email protected] "fn"
  [email protected] " "
  [email protected]
    [email protected] "foo"
  [email protected]
    [email protected] "("
    [email protected] ")"
  [email protected] " "
  [email protected]
    [email protected]
      [email protected] "{"
      [email protected] "\n            "
      [email protected]
        [email protected] "struct"
        [email protected] " "
        [email protected]
          [email protected] "X"
        [email protected] ";"
      [email protected] "\n            "
      [email protected]
        [email protected] "impl"
        [email protected] " "
        [email protected]
          [email protected]
            [email protected]
              [email protected]
                [email protected] "X"
      [email protected] " "
      [email protected]
        [email protected]
          [email protected]
            [email protected]
              [email protected] "fo"
        [email protected] " "
        [email protected]
          [email protected] "{"
          [email protected] " "
          [email protected] "}"
      [email protected] "\n        "
      [email protected] "}"

(there is a show syntax tree command in vscode to get this view)
as youcan see, we parse the fo outside of the impl but within the block expression of the function, so we parse it as an expression. From a recovery perspective this does make sense, so we should probably fix that up in the completion analysis? Not sure,
In the non local item position we g et

  [email protected]
    [email protected] "impl"
    [email protected] " "
    [email protected]
      [email protected]
        [email protected]
          [email protected]
            [email protected] "X"
  [email protected] " "
  [email protected]
    [email protected]
      [email protected]
        [email protected]
          [email protected] "fo"
    [email protected] " "
    [email protected]
      [email protected] "{"
      [email protected] " "
      [email protected] "}"

so there its a macro call. We should already be handling that case (I get a for completion there), so might be good to check how we handle that in completion analysis

[rami3l]

@Veykril Thanks for your pointers! I think I've found a way to be less disruptive, let's see how the CI goes.

Update: Checking impl_.is_some() is still not right. A counter-example would be:

fn foo() {
    struct X;
    impl X { fn bar() { $0 } }
}

[Veykril]

The proper fix will require changes in crates\ide-completion\src\context\analysis.rs as we land in the wrong branch somewhere (due to not accounting for parser recovery)

[Veykril]

rust-analyzer/crates/ide-completion/src/completions/keyword.rs

Lines 7 to 31 in 13ac53e

	pub(crate) fn complete_for_and_where(
	acc: &mut Completions,
	ctx: &CompletionContext<'_>,
	keyword_item: &ast::Item,
	) {
	let mut add_keyword = |kw, snippet| acc.add_keyword_snippet(ctx, kw, snippet);
	match keyword_item {
	Item::Impl(it) => {
	if it.for_token().is_none() && it.trait_().is_none() && it.self_ty().is_some() {
	add_keyword("for", "for $0");
	}
	add_keyword("where", "where $0");
	}
	Item::Enum(_)
	| Item::Fn(_)
	| Item::Struct(_)
	| Item::Trait(_)
	| Item::TypeAlias(_)
	| Item::Union(_) => {
	add_keyword("where", "where $0");
	}
	_ => (),
	}
	}

is where we should be landing in this snippet instead of the expression completion

[rami3l]

rust-analyzer/crates/ide-completion/src/completions/keyword.rs

Lines 7 to 31 in 13ac53e

	pub(crate) fn complete_for_and_where(
	acc: &mut Completions,
	ctx: &CompletionContext<'_>,
	keyword_item: &ast::Item,
	) {
	let mut add_keyword = |kw, snippet| acc.add_keyword_snippet(ctx, kw, snippet);
	match keyword_item {
	Item::Impl(it) => {
	if it.for_token().is_none() && it.trait_().is_none() && it.self_ty().is_some() {
	add_keyword("for", "for $0");
	}
	add_keyword("where", "where $0");
	}
	Item::Enum(_)
	| Item::Fn(_)
	| Item::Struct(_)
	| Item::Trait(_)
	| Item::TypeAlias(_)
	| Item::Union(_) => {
	add_keyword("where", "where $0");
	}
	_ => (),
	}
	}

is where we should be landing in this snippet instead of the expression completion

@Veykril I'm aware of this, it's just that the only possible context of this call is:

rust-analyzer/crates/ide-completion/src/completions.rs

Lines 775 to 777 in 13ac53e

	NameRefKind::Keyword(item) => {
	keyword::complete_for_and_where(acc, ctx, item);
	}

Clearly it's not the same as in a fn, where we mostly expect statements (including items, macro calls and expression statements).

In this case, given how the function is written, I guess PathKind::Expr stands for exactly that: something expression-like. Most of the time you'd want an expression.

Let me see what I can do to improve

rust-analyzer/crates/ide-completion/src/context/analysis.rs

Line 1066 in 13ac53e

PathKind::Expr {

...

[Veykril]

If the preceding token to the cursor is an impl Foo then the only things thats may follow that Foo is a for token, a where token or a curly brace, not an expression. So the completion analysis should compute a NameRefKind::Keyword here, not a NameRefKind::Path

[rami3l]

If the preceding token to the cursor is an impl Foo then the only things thats may follow that Foo is a for token, a where token or a curly brace, not an expression. So the completion analysis should compute a NameRefKind::Keyword here, not a NameRefKind::Path

I see. I believe it works outside of functions because you special-cased it:

rust-analyzer/crates/ide-completion/src/context/analysis.rs

Lines 1157 to 1161 in 13ac53e

	ast::MacroCall(it) => {
	// A macro call in this position is usually a result of parsing recovery, so check that
	if let Some(kind) = inbetween_body_and_decl_check(it.syntax().clone()) {
	return Some(make_res(NameRefKind::Keyword(kind)));
	}

... maybe I can apply a similar hack to this case.

[Veykril]

Yes thats the special case handling it outside of bodies, would be neat if that can be re-used though its probably a bit more tricky

[rami3l]

Yes thats the special case handling it outside of bodies, would be neat if that can be re-used though its probably a bit more tricky

@Veykril So by adding the same hack to records in 3d13c7f, I was able to address the original issue. However, I'm still more interested in the fn foo() { impl X for $0 } case.

[Veykril]

What exaclty is with fn foo() { impl X for $0 }?

[rami3l]

What exaclty is with fn foo() { impl X for $0 }?

The inbetween_body_and_decl_check() hack on records has worked with fn foo() { impl X $0 {} } because $0 {} was resolved to a record, according to your first example in #18005 (comment). However I'm not sure how to handle the case without {}.

fn foo() { impl X fo } gives something like:

 [email protected]
    [email protected] "fn"
    [email protected] " "
    [email protected]
      [email protected] "foo"
    [email protected]
      [email protected] "("
      [email protected] ")"
    [email protected] " "
    [email protected]
      [email protected]
        [email protected] "{"
        [email protected] " "
        [email protected]
          [email protected] "impl"
          [email protected] " "
          [email protected]
            [email protected]
              [email protected]
                [email protected]
                  [email protected] "X"
        [email protected] " "
        [email protected]
          [email protected]
            [email protected]
              [email protected]
                [email protected] "fo"
        [email protected] " "
        [email protected] "}"
  [email protected] "\n"

[Veykril]

Isn't that this case? https://github.com/rust-lang/rust-analyzer/pull/18005/files#diff-9cef2bb04b7b1bc7d74e0d5822c991876dec30dce47004692a99369f18651442R166-R180
I'm sorry I'm confused, fn foo() { impl X for $0 {} } already works fine today for me, your change ought to make fn foo() { impl X fo$0 {} } / fn foo() { impl X $0 {} } work from what I can tell

[rami3l]

I'm sorry I'm confused, fn foo() { impl X for $0 {} } already works fine today for me, your change ought to make fn foo() { impl X fo$0 {} } / fn foo() { impl X $0 {} } work from what I can tell

@Veykril No worries. I believe now I've fixed both of them.

[Veykril]

Thanks!
@bors r+

[bors]

📌 Commit 0b28126 has been approved by Veykril

It is now in the queue for this repository.

[bors]

⌛ Testing commit 0b28126 with merge 2890b10...

[bors]

☀️ Test successful - checks-actions
Approved by: Veykril
Pushing 2890b10 to master...