Resolve module_function visibility

[alexcrocha]

Closes #89 and finishes the singleton-method visibility resolution work started in #780/#781/#782. This PR adds support for resolving module_function visibility:

module Foo
  def bar; end
  module_function :bar
end

Foo.bar           # public singleton method
Foo.new.bar       # NoMethodError (private instance method)

Foo#bar becomes private and Foo.bar is added as a public singleton method.

Two MethodVisibility defs instead of one shared

The indexer emits two MethodVisibility defs at the module_function :bar call site: one routed to the instance side (Foo#bar), one to the singleton side (Foo::<Foo>#bar) via the SINGLETON_METHOD_VISIBILITY flag from #780. Both carry Visibility::ModuleFunction.

A single shared def attached to both declarations doesn't work. definition_to_declaration_id only returns one declaration per def, so the singleton-side declaration would be unreachable from reverse-lookup invalidation. When the source method was removed in a different file, the singleton companion would survive in the graph:

# a.rb
module Foo
  def bar; end
  module_function :bar
end

# b.rb (re-indexed without `def bar`)
module Foo
end

With one shared def, Foo::<Foo>#bar() lingers after a.rb's re-index. Two defs side-step this: each routes to exactly one declaration, and the existing invalidation paths handle both correctly.

Reusing existing primitives

Visibility::ModuleFunction and SINGLETON_METHOD_VISIBILITY together fully describe the singleton-side def. No new flag is needed:

• Visibility::ModuleFunction + no flag: instance-side def, resolves on the lexical owner.
• Visibility::ModuleFunction + SINGLETON_METHOD_VISIBILITY: singleton-side def, resolves on the lexical owner but the resulting declaration lives on the singleton class.
• Any other visibility + SINGLETON_METHOD_VISIBILITY: private_class_method / public_class_method, already handled in Resolve retroactive singleton method visibility changes #781.

Internals don't leak through Graph::visibility()

Graph::visibility() translates Visibility::ModuleFunction to Private (instance) or Public (singleton) based on the flag.

This keeps the two-def model internal. Callers query visibility and get Public/Private/Protected as expected. The SINGLETON_METHOD_VISIBILITY flag, the Visibility::ModuleFunction enum value, and the two-def emission are implementation details that don't leak through Graph's public API.

Defer singleton class creation until the target is confirmed

private_class_method looks up the target on the singleton class, so it has to create the singleton class up front. module_function's singleton-side def looks up on the instance side (Foo directly) and only attaches the resulting declaration to the singleton class. Creating the singleton class up front for the singleton-side def would leave an empty Foo::<Foo> namespace when the target is missing:

module Foo
  module_function :missing
end

The instance-side def emits the undefined method diagnostic. The singleton-side def stays silent and creates nothing, so no synthetic singleton class is left behind.

MethodVisibilityDefinition::id() includes flag bits

Two defs at the same source location share the same uri_id, offset, and str_id. The ID hash now includes flag bits so the siblings get distinct DefinitionIds. Without this, add_definition panics on collision.

In this PR

• emit two MethodVisibility defs for module_function :sym (one per side; singleton-side carries SINGLETON_METHOD_VISIBILITY)
• branch on Visibility::ModuleFunction inside resolve_method_visibilities for the cross-namespace lookup: target on the lexical owner, declaration on the singleton class
• defer get_or_create_singleton_class for the singleton-side def until the target is confirmed
• silence the singleton-side diagnostic for missing targets; the instance-side def owns the diagnostic
• translate Visibility::ModuleFunction to Public (singleton) or Private (instance) in Graph::visibility() based on the flag
• include DefinitionFlags bits in MethodVisibilityDefinition::id() so siblings get distinct IDs

Not in this PR

The inline form (module_function def bar; end) already works through the indexer's pre-existing two-MethodDefinition path; no changes needed here.

Ruby's exact runtime behavior for module_function :a, :missing is not modeled. Ruby raises on :missing only after Foo#a has been made private, and commits no singleton copies for the call. Rubydex resolves each argument independently, so module_function :a, :missing makes Foo#a private AND adds Foo.a as a public singleton method, with a diagnostic for :missing. Editors regularly see code in flux, so modeling each argument independently lets the user keep useful information that Ruby's all-or-nothing raise would discard.

[alexcrocha]

• Resolve module_function visibility #802 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[vinistock]

Do we already support module function and the other visibility operations in the RBS indexer?

[vinistock]

I found these comments to be a bit confusing. I'm not really sure I understand why there are two owners.

[vinistock]

Why did we need to pull this down? Couldn't we create the declaration in the same previous spot?

[vinistock]

I have a good test case to add:

module Foo
  module_function def bar; end
  
  class << self
    private :bar
  end
end

Both Foo#bar() and Foo::<Foo>#bar() should be private.