Fix generic type validation for T::Props and composite members

[dduugg]

Motivation

Fixes #2130.

When a constant is typed with a Tapioca generic type (e.g. a generic interface Foo[Bar]) as a T::Props/T::Struct member, instantiating or setting that member raises a spurious TypeError, even though the value is an instance of the underlying constant. This happens whether the member is typed with the generic directly (const :x, Foo[Bar]) or nested inside a composite type (T::Hash[..., Foo[Bar]], T.all(Foo[Bar], ...)), and it blocks bin/tapioca dsl from loading applications that use generic types in prop/struct members.

Implementation

GenericTypeRegistry::GenericType overrides valid? to validate against the underlying constant (@underlying_type) instead of the generic clone it wraps as raw_type. Previously it subclassed T::Types::Simple, but Simple validates with obj.is_a?(raw_type) and sorbet-runtime has fast paths keyed on is_a?(T::Types::Simple) that read raw_type directly and bypass valid?/recursively_valid? entirely:

• T::Props::Private::SetterFactory uses simple_non_nil_proc/simple_nilable_proc for Simple types, checking val.is_a?(raw_type) inline. This is what a bare const :x, Foo[Bar] (or T.nilable(Foo[Bar])) member hits.
• T.nilable union construction takes a SimplePairUnion fast path for Simple members.

Because raw_type is the clone rather than the underlying constant, every one of these rejects a valid instance. Subclassing T::Types::Base instead removes all of those fast paths, so all validation routes through the valid? override. Base is more minimal than Simple, so the pieces it does not provide are added: name, build_type, and subtype_of_single? (which returns true, matching the always-true <= we already define on the clone in create_generic_type).

This complements #2657, which fixed the T.let/T.cast coercion path but did not cover the setter/composite validation paths.

Tests

Added tests to spec/tapioca/runtime/generic_type_registry_spec.rb covering both a bare T::Struct member (const :member, SampleGenericInterface[Object]) and a composite member (T::Hash[Symbol, SampleGenericInterface[Object]]), each constructed with an implementation instance. Both fail with a TypeError before this change and pass after.

[KaanOzkan]

My agent found a case where sorbet-runtime takes a different code path for T::Types::Simple and bypasses valid? or recursively_valid? checks.

require "tapioca/internal"

module I
  extend T::Generic
  interface!
  E = type_member
end

class C
  include I
end

class S < T::Struct
  const :x, I[Object]
end

S.new(x: C.new)

results in TypeError: Parameter 'x': Can't set S.x to #<C:0x0000000127c91288> (instance of C) - need a I[::Object]

Maybe we shouldn't inherit from T::Types::Simple 🤔 , wdyt?

[dduugg]

Good catch, you're right, and I've taken your suggestion.

The bare T::Struct member hits SetterFactory's is_a?(T::Types::Simple) fast path, which reads raw_type directly and skips both valid? and recursively_valid?. Since our raw_type is the generic clone rather than the underlying constant, val.is_a?(raw_type) is false for an instance of the constant, so the overrides never got a chance to run. (T.nilable(...) union construction has the same Simple-keyed fast path.)

So instead of overriding recursively_valid?, GenericType now subclasses T::Types::Base. That removes the is_a?(Simple) fast paths entirely and routes every validation path through the valid? override. I filled in the pieces Simple had provided (name, build_type, and subtype_of_single?, which just returns true, matching the always-true <= we define on the clone) and dropped the now-unnecessary recursively_valid? override.

Added a spec for your exact repro (bare generic member) alongside the composite one. bin/typecheck and the generic specs are green.

[KaanOzkan]

I think this comment can be improved by changing the language and making it more concise, or be removed completely.

[KaanOzkan]

I guess it's okay to allow everything while running tapioca dsl? There's a similar comment on create_generic_type below.