Skip to content
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

No signatures shown in completion popup #18504

Closed
traviscross opened this issue Nov 11, 2024 · 6 comments
Closed

No signatures shown in completion popup #18504

traviscross opened this issue Nov 11, 2024 · 6 comments

Comments

@traviscross
Copy link

traviscross commented Nov 11, 2024

The issue reported here...

...is a regression triggered by a change in r-a. I've bisected it to commit ba1c914 ("Omit completion fields to be resolved later").

This was part of PR:

This is not fixed by the recent PR:

This regression has made it into beta, and if there is a fix here on the r-a side, we'll probably want to beta-backport that.

See also:

cc @SomeoneToIgnore @Veykril @lnicola

@traviscross
Copy link
Author

traviscross commented Nov 11, 2024

There's been a request on Zulip for details to help a non-Emacs user reproduce this. Here are those details.

Using podman, docker, or your favorite similar tool, create a clean container, install Emacs, install Rust, and minimally configure Emacs:

podman run -ti --rm fedora:41

# Within the container...

# Install Emacs, Rust, and rust-analyzer.
dnf install -y emacs-nw rustup
rustup-init -y
. $HOME/.cargo/env
cd ~
git clone https://github.com/rust-lang/rust-analyzer.git
cd rust-analyzer
git checkout ba1c9146fcca65fa9c40d1e4e73bdcb898a8de46
cargo xtask install --server

# Configure Emacs minimally for lsp-mode.
cat > ~/.emacs <<'EOF'
(setq package-archives
      '(("gnu" . "https://elpa.gnu.org/packages/")
        ("melpa" . "https://melpa.org/packages/")))

(use-package rust-mode :ensure)
(use-package company :ensure)
(use-package lsp-mode :ensure
  :config
  (add-hook 'rust-mode-hook 'lsp-mode))
(use-package yasnippet :ensure
  :config
  (add-hook 'lsp-mode-hook 'yas-minor-mode))
EOF

# Create a project and start Emacs.
cd ~
cargo new playground
cd playground
emacs src/main.rs

Now wait patiently while the dependencies are installed. When done:

  • Press i when prompted to import the project.

Now edit the file to contain:

fn main() {
    "".// Cursor here.
}

The resulting popup will not contain method signatures.

Press C-x C-c (that is, Ctrl-x followed by Ctrl-c) to exit Emacs.

If you then back up r-a by one commit, i.e.:

cd ~/rust-analyzer
git checkout HEAD^
cargo xtask install --server

Then you will get a different and correct result when retesting in Emacs.

@lnicola
Copy link
Member

lnicola commented Jan 4, 2025

I believe this is now fixed, right?

@Veykril
Copy link
Member

Veykril commented Jan 4, 2025

It should be, at least on our end

@Veykril Veykril closed this as completed Jan 4, 2025
@SomeoneToIgnore
Copy link
Contributor

Also to note, nvim had merged hrsh7th/cmp-nvim-lsp#77 and should be fine without any client name checks, on versions that include this change.

@traviscross
Copy link
Author

On the lsp-mode side, it seems that the following PR is the one that will make things work properly:

@wyuenho
Copy link

wyuenho commented Jan 5, 2025

I'm not entirely sure this is fixed. It's at best coincidentally alleviated by surfacing all the info that can be surfaced.

hrsh7th/cmp-nvim-lsp#77 is again treating omission of detail from resolveSupport as preference. As discussed on the Zulip chat, it is not the case that client capabilities should be considered preferences. That servers should not treat it as such, and clients should not have this expectation. In general, if your completionItem#resolveSupport does not look like VS Code's, it's probably wrong.

In addition, as stated on the Zulip chat, the current "fix" is still violating the spec by reversing the intended meaning of labelDetail#detail and labelDetail#description. There's also the additional problem of not supporting clients on <3.17 spec.

Final note, I'm very disappointed by the development process with such an important project in the Rust ecosystem. Code just keeps getting pushed to master with practically no review, description in PR or often times, understanding of the issues at hand. I once again offer help to finally fix this issue once and for all for all clients. Please respond.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants