Function arguments only suggested on subsequent requests
See https://github.com/hrsh7th/nvim-cmp/issues/2065
rustc version: rustc 1.81.0 (eeb90cda1 2024-09-04)
editor or extension: nvim
Here is more discussions over this I found: here
This seems to be a bug in nvim-cmp?
seen with emacs (lsp-mode, rustic) too. Older rust-analyzer versions return "detail" and "documentation" information in "textDocument/completion" response which are missing in 2024-10-18
E.g.
[Trace - 05:53:47 PM] Sending request 'textDocument/completion - (4916)'.
Params: {
"textDocument": {
"uri": "..."
},
"position": {
"line": 1,
"character": 7
},
"context": {
"triggerKind": 2,
"triggerCharacter": "."
}
}
results now in
[Trace - 05:53:47 PM] Received response 'textDocument/completion - (4916)' in 149ms.
Result: {
"isIncomplete": true,
"items": [
...
{
"label": "parse()",
"kind": 2,
"deprecated": null,
"preselect": true,
"sortText": "7ffffffb",
"filterText": "parse",
"insertTextFormat": 2,
"textEdit": {
"newText": "parse()$0",
"insert": {
"start": {
"line": 1,
"character": 7
},
"end": {
"line": 1,
"character": 7
}
},
"replace": {
"start": {
"line": 1,
"character": 7
},
"end": {
"line": 1,
"character": 7
}
}
},
"additionalTextEdits": [],
"data": {
"position": {
"textDocument": {
"uri": "..."
},
"position": {
"line": 1,
"character": 7
}
},
"imports": [],
"version": 55,
"trigger_character": "."
}
},
while previously (2024-10-01 tested)
{
"label": "parse()",
"kind": 2,
"detail": "fn(&self) -> Result<F, <F as FromStr>::Err>",
"documentation": {
"kind": "markdown",
"value": "Parses this string slice into another type.\n\nBecause `parse` is so general, it can cause problems with type\ninference. As such, `parse` is one of the few times you'll see\nthe syntax affectionately known as the 'turbofish': `::<>`. This\nhelps the inference algorithm understand specifically which type\nyou're trying to parse into.\n\n`parse` can parse into any type that implements the [`FromStr`] trait.\n\n# Errors\n\nWill return [`Err`] if it's not possible to parse this string slice into\nthe desired type.\n\n[`Err`]: FromStr::Err\n\n# Examples\n\nBasic usage\n\n```rust\nlet four: u32 = \"4\".parse().unwrap();\n\nassert_eq!(4, four);\n```\n\nUsing the 'turbofish' instead of annotating `four`:\n\n```rust\nlet four = \"4\".parse::<u32>();\n\nassert_eq!(Ok(4), four);\n```\n\nFailing to parse:\n\n```rust\nlet nope = \"j\".parse::<u32>();\n\nassert!(nope.is_err());\n```"
},
"deprecated": null,
"preselect": true,
"sortText": "7ffffffb",
"filterText": "parse",
"insertTextFormat": 2,
"textEdit": {
"newText": "parse()$0",
"insert": {
"start": {
"line": 1,
"character": 7
},
"end": {
"line": 1,
"character": 7
}
},
"replace": {
"start": {
"line": 1,
"character": 7
},
"end": {
"line": 1,
"character": 7
}
}
},
"additionalTextEdits": []
},
was returned.
Completion happened at "".
Also a problem in coq-nvim, just not as severe, because only the first ever autocompletion fails.
That sounds like the client is telling r-a it supports lazily resolving those fields, so the client needs to also send a corresponding resolve request
likely fixed by https://github.com/rust-lang/rust-analyzer/pull/18388