Resolve retroactive singleton method visibility changes

[alexcrocha]

Part of #89 and follows #780, which added the SINGLETON_METHOD_VISIBILITY bit flag and indexed singleton-flagged MethodVisibilityDefinitions.

This PR routes singleton-flagged defs through the singleton class and folds the singleton path into the existing resolve_method_visibilities pass. Visibility definitions are processed after the main convergence loop, so the target method declaration is guaranteed to exist by the time we attach visibility.

For inherited targets like private_class_method :foo where foo comes from a parent class's singleton, we create a child-owned MethodDeclaration on the child's singleton class. This matches what #738 did for instance methods, and what Ruby reports when you ask Child.singleton_class.instance_method(:foo).owner:

class Parent
  def self.foo; end
end

class Child < Parent
  private_class_method :foo
end

Child.singleton_class.instance_method(:foo).owner
# => #<Class:Child>   (Ruby copies the method to Child when visibility changes)

Parent.singleton_class.instance_method(:foo).owner
# => #<Class:Parent>  (untouched on the parent)

Why document-scoped diagnostics for the singleton path

When a singleton target doesn't resolve, the diagnostic attaches to the document, not to the singleton declaration. Walking ancestors via get_or_create_singleton_class(Foo, ...) can synthesize Foo::<Foo> as a side effect, even when it has no real members. For class Foo; private_class_method :missing; end where Foo has no other singleton methods, that synthetic singleton class only exists to host the diagnostic. Attaching to it would leak the declaration on file delete. Document-scoped clears with the file. Instance-method diagnostics keep their existing declaration scope: their owner can't be synthetic.

Source-order processing of visibility defs

Ruby applies visibility statements in the order they appear in source, so the later one wins:

class Foo
  def bar; end
  private :bar
  public :bar          # Ruby: bar is Public
end

This was already broken on main for instance methods; surfaced while wiring up the singleton path, fixed here for both. prepare_units sorted definitions and const_refs by (uri_id, offset) for determinism but left others (which holds the visibility defs queued by handle_remaining_definitions) in IdentityHashMap iteration order, which is bucket-hash order. So Foo#bar could end up Private because the resolver happened to apply public first and private second. Same sort applied to others so the override-order invariant holds for both instance and singleton paths.

In this PR

• branch on is_singleton_method_visibility() inside resolve_method_visibilities: resolve through get_or_create_singleton_class for the singleton path, render "class method" vs "method" in the diagnostic, attach document-scoped (singleton) vs declaration-scoped (instance)
• add Graph::find_singleton_method_visibility_declaration and route through it from the existing Definition::MethodVisibility arm in definition_to_declaration_id when the flag is set
• sort others by (uri_id, offset) in prepare_units so visibility overrides apply in source order

[alexcrocha]

• Extract shared helpers for visibility-call processing #783
• Support array and inline-def arguments to private_class_method #782
• Resolve retroactive singleton method visibility changes #781 👈 (View in Graphite)
• Index private_class_method / public_class_method calls #780
• main

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

[alexcrocha]

Merge activity

• May 7, 8:07 PM UTC: @alexcrocha merged this pull request with Graphite.