Narrow literal-equality (==/!=) and respond_to? guards in flow-sensitive typing

[apiology]

Problem

FlowSensitiveTyping only recognized is_a?/nil?/! for narrowing a variable's type inside a conditional branch. Two common guard styles got no narrowing:

• A bare literal-equality guard left the full declared union type intact, so calling a method that only some union members support still failed at strict typecheck levels even though the guard excludes the literal:

  # @param sections [Array<String>, :not_specified]
  def process(sections)
    return if sections == :not_specified
    sections.each { |s| ... }  # Unresolved call to each on Array<String>, :not_specified
  end

• A respond_to? guard narrowed nothing, so the guarded call itself still failed even though the guard proves the receiver provides it:

  # @param data [Hash{Object => Object}, Array<Object>]
  def dig_into(data, subkey)
    return data[subkey] if data.respond_to?(:key?) && data.key?(subkey)
    # Unresolved call to key? on Hash{Object => Object}, Array<Object>
  end

Solution

• Add process_eq/process_neq, parsing ==/!= comparisons against symbol/string/integer/boolean literals (on either side of the operator) and narrowing the guarded variable the same way is_a? already does, via Pin::BaseVariable#downcast. Falls back safely (ComplexType.try_parse) on literals that can't be represented as type tags.
• Add process_respond_to, asserting a #method duck-type fact on the true path of x.respond_to?(:literal_sym) for an lvar/ivar receiver. It reuses the existing fact plumbing, so it composes with &&/|| through process_and/process_or. No false-path fact is asserted ��� a false respond_to? is not a sound class-level exclusion ��� and non-literal arguments assert nothing. How the duck-type fact is applied to the receiver's type is the policy decision described in the next section.

Reviewable policy: how a duck-type fact narrows

ComplexType#intersect_with now treats a duck-type candidate as a membership test (via duck_types_match?) rather than plain conformance: union arms that provide the method are kept, arms that don't are dropped, and only an arm-less result falls back to the bare duck type (opaque receivers like Object, where the duck type is all we know). So Hash{String => Integer}, Array<Integer> narrowed by #key? becomes Hash{String => Integer} ��� not #key?, which would break other calls on the guarded path. Plain conformance can't express this: UniqueType#conforms_to?'s inferred-side duck_type? short-circuit answers the wrong direction. (When #1231 renames intersect_with to narrow_with, that PR carries this branch through the rename.)

Note

Symbol/string/integer/boolean literals used in type positions get widened to their non-literal class (Symbol, String, etc.) during ComplexType#qualify, per the existing, intentional literal? short-circuit in unique_type.rb (#1201). So narrowing via == lands on the generic class rather than the exact literal - this is consistent with how the rest of the codebase already treats literal types, not something this PR changes. The primary case in the issue (!= excluding a literal member from a union) is unaffected by this and narrows precisely.

Fixes #1296

Test plan

• bundle exec rspec spec/parser/flow_sensitive_typing_spec.rb spec/type_checker/levels/strong_spec.rb (new respond_to? specs fail without the two new commits)
• bundle exec rspec spec/ (full suite; only pre-existing failures: 2 environment-dependent gem_pins examples, identical on base)
• bundle exec rubocop (modified lines clean)
• Confirmed no new solargraph typecheck --level strong problems introduced (pre-existing problems in this file untouched)

���� This PR was written by Claude (Anthropic's AI assistant) on behalf of @apiology.

���� Generated with Claude Code

https://claude.ai/code/session_01H1FEjW6nMpZrWPmeWX9miT