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. |
Beta Was this translation helpful? Give feedback.
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. |
Beta Was this translation helpful? Give feedback.
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: