Function arguments only suggested on subsequent requests

[VVishion]

See hrsh7th/nvim-cmp#2065

rustc version: rustc 1.81.0 (eeb90cda1 2024-09-04)

editor or extension: nvim

[DriedYellowPeach]

Here is more discussions over this I found:
here

[flodiebold]

This seems to be a bug in nvim-cmp?

[ensc]

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 "".

[VVishion]

Also a problem in coq-nvim, just not as severe, because only the first ever autocompletion fails.

[Veykril]

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

[Veykril]

likely fixed by #18388