Skip to content

No signature help returned at ':' #10173

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
gfreezy opened this issue Sep 7, 2021 · 12 comments
Closed

No signature help returned at ':' #10173

gfreezy opened this issue Sep 7, 2021 · 12 comments
Labels
A-parser parser issues C-bug Category: bug S-blocked Status: marked as blocked ❌ on something else such as an RFC or other implementation work.

Comments

@gfreezy
Copy link
Contributor

gfreezy commented Sep 7, 2021

This test should pass.

#[test]
fn test_enum_in_nested_method_in_lambda() {
    check(
        r#"
enum A {
    A,
    B
}

fn bar(_: A) { }

fn main() {
    let foo = Foo;
    std::thread::spawn(move || { bar(A:$0) } );
}
"#,
        expect![[r#"
                fn bar(_: A)
                (<_: A>)
            "#]],
    );
}

Related ast is as below:

@gfreezy gfreezy changed the title Wrong signature help at ':' No signature help returned at ':' Sep 7, 2021
@bjorn3
Copy link
Member

bjorn3 commented Sep 7, 2021

bar(A:$0)

This is not valid rust syntax. You need to remove the :.

@lnicola
Copy link
Member

lnicola commented Sep 7, 2021

Yeah, it works with both A and A::.

@gfreezy
Copy link
Contributor Author

gfreezy commented Sep 7, 2021

Screen.Recording.2021-09-07.at.2.02.06.PM.mov

@gfreezy
Copy link
Contributor Author

gfreezy commented Sep 7, 2021

The signature flips when typing A, A:, A::. It's disturbing.

It always show the outer function signature when the cursor is at an invalid syntax node instead of the current function.

@lnicola
Copy link
Member

lnicola commented Sep 7, 2021

Interestingly, I don't get the thread::spawn docs:

signature.mp4

EDIT:

signature

@gfreezy
Copy link
Contributor Author

gfreezy commented Sep 7, 2021

You need to trigger the bar signature first.
It seems to be the vscode behavior. When language server returns empty signature, vscode show the previous one.

input bar( => bar signature => input A: => spawn signature => input A:: => bar signature

@lnicola
Copy link
Member

lnicola commented Sep 7, 2021

Nope, I still don't see it. But I do get your point.

signature2

@gfreezy
Copy link
Contributor Author

gfreezy commented Sep 7, 2021

rust-analyzer version: 3dae94bf2 2021-09-07 nightly

vscode

Version: 1.60.0
Commit: e7d7e9a9348e6a8cc8c03f877d39cb72e5dfb1ff
Date: 2021-09-01T10:54:53.442Z
Electron: 13.1.8
Chrome: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Darwin x64 20.6.0

@lnicola
Copy link
Member

lnicola commented Sep 7, 2021

Yeah, I'm on the same Code version. Does it happen with the code in your test?

@gfreezy
Copy link
Contributor Author

gfreezy commented Sep 7, 2021

Yeah, I'm on the same Code version. Does it happen with the code in your test?

enum A {
    A,
    B
}

fn bar(_: A) { }

fn main() {
    let foo = Foo;
    std::thread::spawn(move || { 
        bar(A:$0) 
    } // braces is needed 
    );
}

@lnicola
Copy link
Member

lnicola commented Sep 7, 2021

Ah, right. My rustfmt ate those.

bors added a commit that referenced this issue Nov 26, 2022
fix: filter unnecessary completions after colon

close #13597
related: #10173

This PR also happens to fix two extra issues:

1. The test case in https://github.com/rust-lang/rust-analyzer/blob/master/crates/ide-completion/src/tests/attribute.rs#L778-L801 was never triggered in previous behavior.

after:

https://user-images.githubusercontent.com/26110087/201476995-56adf955-0fa7-4f75-ab32-28a8e6cb9504.mp4

<del>
2. completions were triggered even in invalid paths, like

```rust
fn main() {
    core:::::$0
}
```

```rust
#[:::::$0]
struct X;
```

</del>

only `:::` is excluded as discussed in #13611 (comment)
@Veykril Veykril added A-parser parser issues S-blocked Status: marked as blocked ❌ on something else such as an RFC or other implementation work. C-bug Category: bug labels Feb 11, 2023
bors added a commit that referenced this issue Feb 14, 2023
internal: Improve parser recovery for delimited lists

Closes #11188, #10410, #10173

Should probably be merged after the stable release as this might get the parser stuck if I missed something
@Veykril
Copy link
Member

Veykril commented Dec 20, 2023

Closed by #14128

@Veykril Veykril closed this as completed Dec 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-parser parser issues C-bug Category: bug S-blocked Status: marked as blocked ❌ on something else such as an RFC or other implementation work.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants