Materialize singleton classes for namespace declarations

[soutaro]

This PR materializes all singleton class declarations for class and module namespaces.

This is required for descendants enumeration and for find_member_in_ancestors correctness. Without these declarations, a subclass singleton class such as Child::<Child> may not exist when Child is only defined as class Child < Parent, so inherited singleton ancestors and members cannot be found.

Impacted Ruby methods

• Namespace#descendants now includes materialized singleton class declarations.
• Namespace#find_member now returns members inherited through singleton class ancestors.

Other user-facing changes

• Declaration search and completion results exclude materialized singleton class declarations, so newly materialized declarations do not appear as extra workspace symbols.

Performance impact

Because this materializes singleton classes for every namespace declaration, it can add memory use and runtime cost. In practice, the measured impact was small.

• RSS: no measurable increase in synthetic corpus benchmarks or a large internal Ruby codebase
• Runtime: about 1.8% slower on a large internal Ruby codebase; not measurable in synthetic corpus benchmarks

Validation

• Confirmed the superclass-extend descendants regression fails on origin/main: Extension.descendants lacks Child::<Child>
• Confirmed the singleton find_member regression fails on origin/main: Child::<Child> returns DeclarationNotFound
• shadowenv exec -- cargo test -p rubydex find_member_in_ancestors_returns_inherited_singleton_member
• shadowenv exec -- bundle exec ruby -Itest test/declaration_test.rb -n /test_find_member_returns_inherited_members_on_singleton_class/
• shadowenv exec -- cargo test -p rubydex exact_match_empty_query_returns_all
• shadowenv exec -- cargo test -p rubydex
• shadowenv exec -- bundle exec rake ruby_test
• git diff --check HEAD~2..HEAD

[soutaro]

This simply drops all singleton class declarations from search results. For UX, we may want to keep explicit singleton class declarations from class <<, and only filter out synthetic ones.

[st0012]

How about we still always list single class decls from Rubydex, and we let the client to decide whether to show them?

@vinistock WDYT?

[vinistock]

I'm a bit torn here. Filtering on the Rust side allows for great performance and parallelism. Additionally, the common case is almost never to search for the singleton class name, but instead the attached object name.

It's also still possible to reach the singleton class by searching for the attached object and then directly accessing.

[soutaro]

I’ll keep the code above for now. We can revisit it later if it causes another issue.

[st0012]

How about we still always list single class decls from Rubydex, and we let the client to decide whether to show them?

@vinistock WDYT?

[vinistock]

If we make the move to always create singleton classes eagerly, then I think the right layer for the fix would to create a singleton class whenever the class gets created. It may require studying the impact for lazily creating singleton class of singleton classes (e.g.: Foo::<Foo>::<<Foo>>).

Also, I wonder if it would still be worth trying to minimize the amount of work. So far, if no operation in the code reaches into the singleton class, we've been considering that it doesn't exist in our modelling (lazy). Maybe we should only create singleton classes for the descendants of existing singleton classes (instead of all of them).

[soutaro]

@vinistock

think the right layer for the fix would to create a singleton class whenever the class gets created.

It makes sense. Will fix the PR to do so.

And we still need to keep the lazy path for meta-singleton classes anyway. Ancestor/descendant enumeration will remain broken for meta-singleton classes, but that seems acceptable.

if no operation in the code reaches into the singleton class, we've been considering that it doesn't exist in our modelling

It would be possible, but it would require a significant re-architecture of the ancestor/descendant handling. I think we should keep the eager materialization strategy for this issue for now.