Resolve retroactive singleton method visibility changes#781
Open
alexcrocha wants to merge 1 commit into05-04-index_private_class_method___public_class_method_callsfrom
Open
Conversation
Contributor
Author
|
Warning This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
This stack of pull requests is managed by Graphite. Learn more about stacking. |
This was referenced May 5, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

Part of #89 and follows #780, which indexed
SingletonMethodVisibilityDefinitionand left theDefinition::SingletonMethodVisibilityarm in resolution as a no-op.This PR resolves retroactive
private_class_methodandpublic_class_methodcalls. We process visibility definitions 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 :foowherefoocomes from a parent class's singleton, we create a child-ownedMethodDeclarationon the child's singleton class. This matches what #738 did for instance methods, and what CRuby reports when you askChild.singleton_class.instance_method(:foo).owner:Why document-scoped diagnostics
When the target doesn't resolve, we emit
UndefinedSingletonMethodVisibilityTargetattached to the document, not to the singleton declaration. Walking ancestors viaget_or_create_singleton_class(Foo, ...)can createFoo::<Foo>as a side effect, even when it has no real members. Forclass Foo; private_class_method :missing; endwhereFoohas no other singleton methods, that synthesized singleton class only exists to host the diagnostic. Attaching to it would leak the declaration on file delete. Document-scoped clears with the file.In this PR
resolve_singleton_method_visibilities, mirroringresolve_method_visibilitieshandle_remaining_definitionsvia a new armGraph::visibilityarm forSingletonMethodVisibilityso callers can read it backUndefinedSingletonMethodVisibilityTarget(document-scoped) when the target is missing