Closed render1980 closed 2 years ago
Thanks for reporting @render1980.
Move to parent method of Class / trait (in Scala)
So this actually needs to be used the other way around, not at the parent site. So for example
trait Thing {
def a: Int <-- it won't work here
def b: Int <-- it won't work here
}
class OtherThing extends Thing {
override def a: Int = ??? <-- it would work here
override def b: Int = ??? <-- it would work here
}
If you want to see the implementation on the parent member, you'd want to use the goto implementations mapping. If there are more than 1, it will show them all to you and you can choose.
All that to say, exception shouldn't be thrown like that, so we can probably fix that to ensure it doesn't lead to a red herring like this.
Hi @ckipp01
Thank you for the response.
If you want to see the implementation on the parent member, you'd want to use the goto implementations mapping.
If I want to see the implementations on the parent member I also can use coc-implementation
command and it works (at the parent site).
But currently these both methods (metals.super-method-hierarchy
and metals.goto-super-method
) don't work on both sites and produce the same error:
[coc.nvim]: UnhandledRejection: Internal error.
Error: Internal error.
at Ol (~/.vim/plugged/coc.nvim/build/index.js:37:224)
at Sp (~/.vim/plugged/coc.nvim/build/index.js:36:11261)
at Immediate.<anonymous> (/Users/fungus/.vim/plugged/coc.nvim/build/index.js:36:11111)
at processImmediate (internal/timers.js:461:21)
@render1980 does it work on the minimal example that I have up above, or is this only happening in your project? I'll move this back over to the coc-metals repo. I don't actually even have coc-metals set up for myself with nvim anymore as I solely use nvim-metals now, so it might take a bit for me to get to this. I'm surprised something is going wrong with this though as there isn't a whole lot going on, but one thing that might help is if you can grab the lsp.trace logs for the resquest/response. You can see how to get those here: https://scalameta.org/metals/docs/contributors/getting-started#json-rpc-trace
It doesn't work neither in this minimal example nor in my project.
Trace for your example:
[Trace - 00:23:27 AM] Received request 'workspace/executeCommand - (33)'
Params: {
"command": "goto-super-method",
"arguments": [
{
"document": "file:///~/go/src/scala_test/src/main/scala/Test.scala",
"position": {
"line": 6,
"character": 15
}
}
]
}
[Trace - 00:23:27 AM] Sending response 'workspace/executeCommand - (33)'. Processing request took 5ms
Result: null
I can confirm that this doesn't work in VSCode too. Previously parameters were extracted into specific GotoSuperMethodParams
But then it was replaced on TextDocumentPositionParams
that isn't compatible with old format.
Yup, I'm actually working on a fix atm @dos65
Bug description
Hello!
Got problem with coc commands
metals.super-method-hierarchy
andmetals.goto-super-method
using nvim coc-metals plugin in Scala project.To Reproduce Steps:
.scala
source code file in neovim:CocCommand
and choosemetals.super-method-hierarchy
ormetals.goto-super-method
:CocOpenLog
to watch errorsExpected behavior
Methods of children classes are shown for
metals.super-method-hierarchy
command. Going to super method formetals.goto-super-method
command.Diagnostics information
codeLens is enabled in coc settings:
lsp4j
which is used by metals:Tried
The problem is still the same.
Have no idea what's the reason of the problem.