Local variable type inference doesn't seem to work. #4161
|
Hello everyone. I'm new to ruby and im trying to setup my editor (emacs + eglot) to use ruby-lsp in my ruby projects. Now, the setup seem to work fine, but i'm not sure its working as intended or not. Here is my situation: # The language server cant infer that this variable is an string? I get absolutely no hover info for the variable "sentence":
sentence = "hello"
# No completion? It does not offer me any methods over this string(split,slice,upcase...)
sentence.
# The completion only works for variables and classes .e.g:
sentence
String
ObjectI just wanna know to if its by design? or i have misconfigured something. |
Replies: 1 comment 1 reply
|
This is currently expected behavior, not an Eglot misconfiguration. Ruby LSP can complete calls when it can resolve the receiver directly, but it does not carry a full inferred type through local-variable assignments. The maintainers described the same case in issue #3407: direct calls such as Your string example crosses that same boundary: "hello".upcase # direct literal receiver: Ruby LSP can know it is a String
sentence = "hello"
sentence.upcase # local-variable type is not flowed from the assignmentSo there are two useful checks:
For accurate completion after assignments, the Ruby LSP design documentation recommends adopting a type system/type checker such as Sorbet or Steep. Ruby LSP itself deliberately falls back to syntax/index-based heuristics rather than shipping a complete type system. If this explains what you are seeing, please mark it as the accepted answer so other Emacs/Eglot users can distinguish the inference limitation from a broken setup. |
This is currently expected behavior, not an Eglot misconfiguration.
Ruby LSP can complete calls when it can resolve the receiver directly, but it does not carry a full inferred type through local-variable assignments. The maintainers described the same case in issue #3407: direct calls such as
SomeClass.new.some_methodcan be resolved, while carrying the type throughx = SomeClass.new; x.some_methodwould require type-flow analysis and at least part of a type system. Their exploration in #2421 concluded that the accuracy gain without annotations would be too small, so they did not implement it.Your string example crosses that same boundary: