Index methods

[soutaro]

• Index method
• Index method parameters
• Add test to confirm resolution works
• What should we do for overloads??

[Morriar]

This can panic if a subsequent comment line has fewer leading spaces than indent_len. For example, if the first line has 4 spaces of indentation but a later line accidentally starts at column 0, line[4..] would panic with an out-of-bounds string slice.

Might be safer to use line.get(indent_len..).unwrap_or(line) here:

Suggested change

	line[indent_len..].to_string()
	line.get(indent_len..).unwrap_or(line).to_string()

[vinistock]

We should have the mechanisms for indexing singleton methods. Not sure what singleton_instance method means.

[soutaro]

I’ve been working on instance method support because it's easier to finish.

I’ll work on singleton method support once I finish indexing instance methods.
singleton_instance is for module_function. (Yeah, that makes things even more complicated. 😄)

[vinistock]

I was reflecting on this for the parameters. I think we have a few options, but my suggestion is that we make parameters in MethodDefinition an enum.

enum MethodParameters {
  Simple(Signature),
  Overloaded(Vec<Signature>),
}

// where Signature just holds the vector of parameters for convenience

The reason I feel like this is the best option is because a lot of methods in RBS will not have overloads. If we were to create a separate RBSMethodDefinition that always accepted a vector of signatures, we would pay the price of allocating vectors for a bunch of RBS methods that don't have overloads.

I believe we'll reduce our memory usage and keep the implementation simple by simply allowing method defs to accept a single signature or overloads.

[soutaro]

@vinistock

Introducing a new enum like MethodParameters sounds better to me, because we can add more variants when we need, like overloaded method definitions or untyped method types ((?) -> T) in RBS.

However the memory footprint will be slightly bigger than Vec<Signature> (24 bytes vs 32 bytes with the enum) with fewer heap allocations. Does it make sense?

Quote from claude-code analysis:

  ┌────────────────────────┬────────────────┬───────────────────────┐
  │                        │ Vec<Signature> │ MethodParameters enum │
  ├────────────────────────┼────────────────┼───────────────────────┤
  │ Inline size            │ 24 bytes       │ 32 bytes              │
  ├────────────────────────┼────────────────┼───────────────────────┤
  │ Single-sig heap allocs │ 2              │ 1                     │
  ├────────────────────────┼────────────────┼───────────────────────┤
  │ Multi-sig heap allocs  │ 2              │ 2                     │
  ├────────────────────────┼────────────────┼───────────────────────┤
  │ MethodDefinition size  │ 112 (current)  │ 120                   │
  └────────────────────────┴────────────────┴───────────────────────┘

  The enum saves one heap allocation for every single-signature method but costs 8 bytes more per MethodDefinition. For multi-signature methods the alloc count is the same.

[st0012]

@soutaro can you calculate how that'll accumulate to be in our monolith?

[soutaro]

@st0012 Good point!

In core/shopify, there are 376,097 method definitions, and the difference between the two data structures is about 3 MB. The max RSS is 4830.97 MB, so 3 / 4830.97 is about 0.06%.

I don’t think this difference matters, so we can go with the enum definition. 💪