Bogus snippet completions suggested

[WhyNotHugo]

> rust-analyzer --version
rust-analyzer 2025.05.19
> rustc -V
rustc 1.87.0 (17067e9ac 2025-05-09) (Alpine Linux 1.87.0-r0)
> nvim --version
NVIM v0.11.1
Build type: MinSizeRel
LuaJIT 2.1.1723681758

code snippet to reproduce:

fn main() {
    let s = String::new();
    s.
}

Please the cursor at the end of line s. and trigger auto-completion. rust-analyzer suggests a bunch of snippets: let~ letm, ref~, box~, etc…

All of these are completely bogus in this context. For example, box~ expands to Box::new. The result of applying it is:

fn main() {
    let s = String::new();
    s.Box::new
}

This isn't even valid syntax. These snippets suggestions are completely ignoring context (are they a new feature? I've never seen them before), and add a lot of noise. In most situations, actually valid suggestions are buried behind a bunch of suggestions that don't make sense.

In these situations, snippets should not be suggested; contextual suggestions (like methods on the String type) should be the only suggestions.

[ChayimFriedman2]

I cannot reproduce in VSCode, so this is probably something about your LSP client not properly supporting snippets.

[WhyNotHugo]

It's the LSP which sends the bogus auto-completion suggestions in this context.

What exactly do you mean by "properly supporting snippets"?

[ChayimFriedman2]

It's the LSP which sends the bogus auto-completion suggestions in this context.

Did you check the response manually? What is it? Given it works in VSCode I suspect it's not the case.

What exactly do you mean by "properly supporting snippets"?

I dunno, not properly implementing them or something.

[flodiebold]

These are postfix snippets. When you select e.g. the box snippet, it should expand to Box::new(s), not s.Box::new. These are only sent if your client indicates it supports snippets, in which case it should be able to correctly expand them (not give the result that you posted). If you don't like them, you can turn them off with rust-analyzer.completion.postfix.enable though. (Also, where they show up in the completion list is also significantly controlled by the client. They shouldn't usually show up as the first results.)

[WhyNotHugo]

Continuing #19968 here as indicated. I'll copy-paste the issue here to provide context:

---

> rust-analyzer --version
rust-analyzer 2025.05.19
> rustc -V
rustc 1.87.0 (17067e9ac 2025-05-09) (Alpine Linux 1.87.0-r0)
> nvim --version
NVIM v0.11.1
Build type: MinSizeRel
LuaJIT 2.1.1723681758
``

**code snippet to reproduce**:
```rust
fn main() {
    let s = String::new();
    s.
}

Please the cursor at the end of line s. and trigger auto-completion. rust-analyzer suggests a bunch of snippets: let~ letm, ref~, box~, etc…

When using the "expand" shortcut, these snippets are expanded to things like Box::new(s).

These suggestions don't make sense in this context; if I type s., I expect to see completion for associated function calls, not potential re-writes for this.

The main issue at hand, is that these suggestions (about a dozen) drown out the actually relevant suggestions; one that are consistent to what I've just typed.

These suggestions should only be shown when they are consistent with what one has typed in the code editor.

---

@ChayimFriedman2 mentioned that this issue is not evident in VSCode simply due to implementation details of the presentational UI.

does neovim sorts by sortText in descending order?

It depends on what you use for the UI itself. I'm using nvim-cmp, which uses the following criteria to sort items:

https://github.com/hrsh7th/nvim-cmp/blob/b5311ab3ed9c846b585c0c15b7559be131ec4be9/lua/cmp/config/default.lua#L66-L80

It seems that score and locality have higher precedence.

I think trying to re-order irrelevant suggestions so they're not in the way is not the ideal fix for this; it would be best to simply avoid generating irrelevant suggestions.

[flodiebold]

Again, you can just turn off the snippet suggestions if you don't like them. They're not irrelevant in this situation, so there is no reason to not generate them in this specific situation.

[WhyNotHugo]

I don't want to disable them because they are useful in the correct context.

If I type some_var, or if the cursor is on an empty line, these suggestions are useful.

If I type some_var., then I'm obviously trying to call an associated function, and these suggestions are irrelevant, and drown out relevant suggestions.

I really do want them to remain enabled—but only to be shown in the correct context.

[ChayimFriedman2]

If you only want to disable postfix snippets (those that occur after you type a dot), that's also possible.

[flodiebold]

These snippets only activate when you're writing some_var.. That's their intention: you write some expression, then you can e.g. write .box to wrap the whole thing in Box::new(). That's what the postfix in rust-analyzer.completion.postfix.enable means.

[ChayimFriedman2]

We tell the clients how to sort based on semantics information, which they don't have. If clients choose to ignore this and override our hints, there is nothing we can do. Arguably, that's a bug in nvim-cmp. As @flodiebold said, those completions are often helpful (at least with correct sorting) and therefore we will not disable them by default; you can do that for your own if you want.