Unrelated comment removes superclass pin?

[apiology]

Commenting out a line of code inside a class body — an ordinary thing to do while iterating on a list of test cases — can make Solargraph lose that class's superclass entirely. Every inherited method then reports Unresolved call throughout the class, including on lines above the comment, so the reported locations point nowhere near the cause. In our codebase this cost 14 suppression comments in one file and went undiagnosed for months, because "a comment changed type resolution" is not a hypothesis anyone reaches for.

# frozen_string_literal: true

class Base
  # @return [String]
  def greet
    'hi'
  end
end

class Sub < Base
  # [:b, { c: :d }]

  # @return [void]
  def call_it
    greet
  end
end

$ solargraph typecheck --level strong probe.rb
probe.rb:15: Unresolved call to greet
1 problem found.

Expected: 0 problems found. Rewording that line as prose (# b maps c to d) passes. Verified on master 8fda6338 ("Release 0.60.3"), ruby 3.3.12, rbs 4.0.3.

The trigger looks specific to inline RBS parsing of a tuple containing a record type, in a plain comment that was never marked as an annotation:

Comment	Result
# [{ c: :d }] — RBS tuple-of-record	breaks
# [{ c: Integer }] — RBS tuple-of-record	breaks
# [{}] — RBS tuple-of-empty-record	breaks
# [{ String => Integer }] — YARD hash type	clean
# [Integer, String] — RBS tuple, no record	clean
# { c: Integer } — RBS record, no brackets	clean
# [:b], # [1], # [], # {}, prose	clean

It needs brackets around a brace-record — neither part alone does it, and YARD's own hash-type syntax ({K => V}) is unaffected, which is what points at RBS rather than YARD. The enclosing array literal the comment originally sat in is not required, nor .freeze, nor a trailing comma. Note the comment carries no #: marker, so whatever is reading it is doing so speculatively.

Filed by Claude (Anthropic's Claude Code) on behalf of @apiology.