Initialize signature showing Object.new signature but not the specific class signature

[dgmora]

Description

Reproduction steps

1. Create a class with an initialize method, give it no documentation.
2. In another place, instantiate this class
3. The signature help displays class.rbs help. It doesn't matter if the signature is different or no.
4. I would expect at least to see the signature.

This may be an issue with the neovim/lsp configuration, I'm wondering if other people see this too. I have seen this with my classes, but also with gems. The classes for the gems are loaded correctly, however when I try to instantiate it, I don't see the signature. Could be related to #2553 ?

I've created a Dockerfile where you can see this happening. There are some annoying warnings, I need to update the Dockerfile.

curl -o Dockerfile https://gist.githubusercontent.com/dgmora/f869b0692db5fafdf6d43090ec9cb46f/raw/Dockerfile && \
  docker build -t lazyvim-lsp . && \
  docker run -it lazyvim-lsp
# `nvim` to start neovim
# inside:
#   `<space>`  to see available keymaps (and wait) 
#   `<space>e` to toggle filetree
#   `a`        to create a file in the file tree

[vinistock]

Thank you for the bug report! This is not related to the PR you mentioned, it was always like this. Essentially, we need to map the fact that when invoking new, the signature you should see is the one for initialize (i.e.: the names don't match).

Sorbet solves this with what it calls intrinsics, defining custom type checking rules for certain method calls. We would need something similar to that so that we can create mappings between what is invoked and what the user wants to see.

This is the same case for something like perform_now or perform_later in Rails, where you don't define those methods, but instead define perform - and that's the one you're interested in seeing documentation for and jumping to.

Note: important to remember for whoever ends up tackling this issue that Ruby does allow you to override self.new and do something completely different that doesn't even involve initialize. We will need to make a decision here: do we want to pay the performance price to check if the user has overridden self.new and favour correctness or always consider new -> initialize and prefer better performance?

[dgmora]

Thanks for the clarification!

I've also noticed that if the first class has a method like

class MyExample
  def test
    puts 'hi'
  end
  ...
end

Doing MyExample.new.te doesn't show test. Is that related?

[vinistock]

Not exactly. That would require some special handling for the new method in our type inferrer.

However, we explored type flow analysis in #2421 and concluded that the effort vs benefit was not worth it at the moment (you essentially need to build an entire type checker to get that working). I say that because of this:

# We can make this work properly because all we need to look into is the immediate receiver
MyExample.new.test

# This requires more sophisticated flow analysis, which we will not invest effort at this time
# Although this specific example might look simple, the mechanisms to ensure proper type flow analysis
# are not. We need to properly track scopes, create an internal type system so that we can represent
# unions if variables are set conditionally and many other fundamental pieces of a full fledged type
# checker
a = MyExample.new
a.test

[github-actions]

This issue is being marked as stale because there was no activity in the last 2 months

[andyw8]

Let's add this to the roadmap: #2950