Index method definitions from RBS

[soutaro]

This PR implements indexing method definitions def from RBS.

• Support all parameter kinds: required/optional positional, rest, post, required/optional keyword, rest keyword, block, and untyped parameters (?) -> void
• Support overloaded method signatures (def foo: (String) -> Integer | (Integer) -> String)
• Handle visibility (public/private), singleton methods (def self.foo), and module_function (def self?.foo)
• Generate default names for unnamed RBS parameters (arg0, arg1, ..., args, kwargs, block)

[vinistock]

Left some non blocking comments

[vinistock]

Are we doing the same for the Ruby indexer? I have the gut feeling that we would actually prefer not including the **.

For example, if we want to rename the parameter, we wouldn't edit the **, but only what comes after.

Anyway, let's just ensure it's consistent between both indexers.

[soutaro]

I'm fine to drop the **. Will fix the code to align with Ruby indexer. 👍

The problem is RBS type declaration may not have the name of parameter, and the &block parameter syntax is not supported.

def foo: (String, *Integer) { (Integer) -> String } -> void
          ^^^^^^   ^^^^^^^                                     ==> Unnamed parameters
                            ^^^^^^^^^^^^^^^^^^^^^^^            ==> No &block parameter

Assigning parameter names automatically like arg0 and &block would make sense for now.

[vinistock]

Interesting, I hadn't considered that. Let's indeed use arg0 and block for now, but later we may need to reconsider how we handle parameters.

I guess there are two main scenarios:

• An RBS file defines a method we did not know about. This case may need to default to arg0 and block, although it's a bit unfortunate. It would be nice if we could have proper names for them
• An RBS file only adds types to an existing method we discovered from Ruby. In this case, the RBS annotations are essentially only assigning types, so maybe this one is handled a bit differently

Anyway, a problem for later.

[soutaro]

Hmm. Mixing RBS and Ruby method definitions is a bit complicated.

I think there are two directions for using method signatures:

1. For callers — type checking call expressions, showing documentation, parameter hints, ...
2. For def implementation — type checking the implementation body (not sure yet what rubydex will do here)

In Steep:

1. For callers RBS is the source of truth. (Steep simply ignores Ruby methods if RBS is missing.)
2. For def implementations, it reasons the type of each parameter in the Ruby def syntax from RBS method types to type check the method body.

I think rubydex can take a similar approach for callers: use RBS information when it exists, and fall back to signatures from the Ruby method definition when RBS is missing. When RBS type definition exists, the absence of parameter names may not be a big problem, since the parameter types itself would help very well.

[vinistock]

This seems like something we should probably add to the RBS crate for convenience (which we can do separately if preferred).

Essentially a name method that returns the byte slice.

[soutaro]

I'd like to finish working on this PR. Will fixup the commit and improve the signature registration. And then merge this PR leaving other things to successor PRs.

[soutaro]

I want this utility to test where an offset points to.