Describe the bug
When attempting to rename a symbol, nothing happens.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Input asking for the new name.
Screenshots
The following error can be seen in the client log:
[ERROR][2021-11-16 16:15:30] .../vim/lsp/rpc.lua:412 "rpc" "clojure-lsp" "stderr" "Nov 16, 2021 4:15:30 PM org.eclipse.lsp4j.jsonrpc.json.StreamMessageProducer fireError\nSEVERE: Unable to invoke no-args constructor for class org.eclipse.lsp4j.PrepareRenameParams. Registering an InstanceCreator with Gson for this type may fix this problem.\njava.lang.RuntimeException: Unable to invoke no-args constructor for class org.eclipse.lsp4j.PrepareRenameParams. Registering an InstanceCreator with Gson for this type may fix this problem.\n\tat com.google.gson.internal.ConstructorConstructor$14.construct(ConstructorConstructor.java:228)\n\tat com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.read(ReflectiveTypeAdapterFactory.java:212)\n\tat com.google.gson.Gson.fromJson(Gson.java:932)\n\tat com.google.gson.Gson.fromJson(Gson.java:1003)\n\tat org.eclipse.lsp4j.jsonrpc.json.adapters.MessageTypeAdapter.fromJson(MessageTypeAdapter.java:339)\n\tat org.eclipse.lsp4j.jsonrpc.json.adapters.MessageTypeAdapter.parseParams(MessageTypeAdapter.java:298)\n\tat org.eclipse.lsp4j.jsonrpc.json.adapters.MessageTypeAdapter.read(MessageTypeAdapter.java:134)\n\tat org.eclipse.lsp4j.jsonrpc.json.adapters.MessageTypeAdapter.read(MessageTypeAdapter.java:55)\n\tat com.google.gson.Gson.fromJson(Gson.java:932)\n\tat org.eclipse.lsp4j.jsonrpc.json.MessageJsonHandler.parseMessage(MessageJsonHandler.java:119)\n\tat org.eclipse.lsp4j.jsonrpc.json.MessageJsonHandler.parseMessage(MessageJsonHandler.java:114)\n\tat org.eclipse.lsp4j.jsonrpc.json.StreamMessageProducer.handleMessage(StreamMessageProducer.java:193)\n\tat org.eclipse.lsp4j.jsonrpc.json.StreamMessageProducer.listen(StreamMessageProducer.java:94)\n\tat org.eclipse.lsp4j.jsonrpc.json.ConcurrentMessageProcessor.run(ConcurrentMessageProcessor.java:113)\n\tat java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)\n\tat java.util.concurrent.FutureTask.run(FutureTask.java:264)\n\tat java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)\n\tat java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)\n\tat java.lang.Thread.run(Thread.java:829)\n\tat com.oracle.svm.core.thread.JavaThreads.threadStartRoutine(JavaThreads.java:567)\n\tat com.oracle.svm.core.posix.thread.PosixJavaThreads.pthreadStartRoutine(PosixJavaThreads.java:192)\nCaused by: java.lang.reflect.InvocationTargetException\n\tat java.lang.reflect.Method.invoke(Method.java:566)\n\tat com.google.gson.internal.UnsafeAllocator$1.newInstance(UnsafeAllocator.java:50)\n\tat com.google.gson.internal.ConstructorConstructor$14.construct(ConstructorConstructor.java:225)\n\t... 20 more\nCaused by: java.lang.IllegalArgumentException: Class org.eclipse.lsp4j.PrepareRenameParams is instantiated reflectively but was never registered. Register the class by using org.graalvm.nativeimage.hosted.RuntimeReflection\n\tat com.oracle.svm.core.graal.snippets.SubstrateAllocationSnippets.hubErrorStub(SubstrateAllocationSnippets.java:258)\n\tat sun.misc.Unsafe.allocateInstance(Unsafe.java:840)\n\t... 23 more\n\n"
{ id = 8, jsonrpc = "2.0", method = "textDocument/prepareRename", params = { position = { character = 24, line = 0 }, textDocument = { uri = "file:///[redacted]" } }}
Log - clojure-lsp
2021-11-16T19:24:06.419Z mexicali INFO [clojure-lsp.source-paths:134] - Automatically resolved source-paths from project.clj: #{"src" "src/main/clojure" "test" "src/test/clojure"}
2021-11-16T19:24:13.479Z mexicali INFO [clojure-lsp.db:?] - Reading analysis cache from Datalevin db took 6.91 secs
2021-11-16T19:24:13.480Z mexicali INFO [clojure-lsp.crawler:154] - Using cached classpath for project root [redacted]
2021-11-16T19:24:13.481Z mexicali INFO [clojure-lsp.crawler:234] - Analyzing source paths for project root [redacted]
2021-11-16T19:24:13.483Z mexicali INFO [clojure-lsp.feature.clojuredocs:40] - Refreshing clojuredocs cache...
2021-11-16T19:24:13.983Z mexicali INFO [clojure-lsp.crawler:?] - Project only paths analyzed, took 0.50 secs
2021-11-16T19:24:14.011Z mexicali DEBUG [clojure-lsp.server:?] - :initialize 7716ms
2021-11-16T19:24:14.057Z mexicali INFO [clojure-lsp.server:350] - Initialized!
2021-11-16T19:24:14.062Z mexicali DEBUG [clojure-lsp.server:?] - :initialized 5ms
2021-11-16T19:24:14.172Z mexicali INFO [clojure-lsp.kondo:?] - Linting whole project files took 0.18 secs
2021-11-16T19:24:15.141Z mexicali DEBUG [clojure-lsp.server:?] - :didOpen 1075ms
2021-11-16T19:24:17.104Z mexicali INFO [clojure-lsp.feature.clojuredocs:?] - Refreshing clojuredocs cache took 3.62 secs.
User details (please complete the following information):
clojure-lsp 2021.10.20-16.49.47 clj-kondo 2021.10.20-SNAPSHOTAdditional context
Rename has been working previously for me in the same neovim and clojure-lsp versions. I'm trying to narrow down what might have changed since.
@fuadsaud that is a graalvm reflection error on clojure-lsp, I will fix it, but it probably started to happen with some bump on your neovim version which added support for PrepareRename
@fuadsaud it seems that neovim is not checking if the server supports textDocumentprepareRename request before calling it like emacs lsp-mode does, maybe @mjlbach knows something, even so, I'll fix the graalvm issue.
cc @mfussenegger, I think it's because we use the santized value for rename and don't individual check the prepareRename capability explicitly (this commit, which I reviewed, introduced the issue https://github.com/neovim/neovim/commit/fcc11d5942779b57257a75e995068fedbf116e34)
Most helpful comment
cc @mfussenegger, I think it's because we use the santized value for rename and don't individual check the prepareRename capability explicitly (this commit, which I reviewed, introduced the issue https://github.com/neovim/neovim/commit/fcc11d5942779b57257a75e995068fedbf116e34)