Resolve type variables of a reopened declaration by position

[sinsoku]

Motivation

RBS 4.1 renamed the core's type parameters (Array[Elem] became Array[E]), but RBS files in rbs collections still reopen them with the old names: activesupport in gem_rbs_collection has module Enumerable[unchecked out Elem], and so does the rbs gem's own sig/shims/enumerable.rbs. RBS allows this, as validate_type_params compares the parameters after renaming them.

TypeProf keyed type variable substitution by the names of a single declaration, so with such a collection any method lookup through Enumerable crashed and the whole file failed to analyze:

$ bin/typeprof lib/typeprof/cli/cli.rb
lib/typeprof/core/ast/sig_type.rb:887:in 'TypeProf::Core::AST::SigTyVarNode#covariant_vertex0': unknown type variable: Elem (RuntimeError)
        from lib/typeprof/core/env.rb:142:in 'block in TypeProf::Core::GlobalEnv#get_instance_type'
        from lib/typeprof/core/graph/box.rb:1269:in 'block in TypeProf::Core::MethodCallBox#resolve_included_modules'

#468 met the same limitation with TypeProf's own shim and aligned the shim's names with the core (91bd108), which is not an option for third-party RBS.

Changes

SigTyVarNode maps a name missing from the substitution to the entity's name at the same position in its own declaration. This is done at lookup time instead of renaming the AST, because the entity's names can change when a declaration is removed in the LSP, while the position stays the same. The workaround from #468 is reverted, so the shim exercises the mapping every time the core RBS is loaded.

Verification

• CI passes.
• bin/typeprof lib with an rbs_collection.yaml that includes the rbs gem completes without errors.
• The new scenarios fail before the fix with unknown type variable: X / T.

🤖 Generated with Claude Code

[mame]

Thanks! Just one place I'd like to simplify. If this looks good to you, feel free
to merge it yourself.

I've applied the suggestion, so I'm removing the "request-changes" status to proceed with the merge.