Name where inference stopped in typecheck inference errors

[apiology]

Problem

A local with a declared type, whose expression calls a method that does not exist:

class Report
  # @return [void]
  def run
    # @type [String]
    v = 'a'.no_such.upcase
    v
    nil
  end
end

typecheck --level strong reports one problem for this file, and it names only the variable:

example1.rb:5: Variable type could not be inferred for v

Nothing says which of 'a', no_such, or upcase inference stopped at, and there is no other problem reported in the file to cross-reference. Diagnosing it means bisecting the expression by hand.

The same gap appears in code with no tags at all, where the method-return check fires instead:

class Report
  # @return [Array<String>]
  def rows
    ys = fetch.to_a.compact
    ys
  end

  # @return [Rows::Unknown]
  def fetch
    fetch
  end
end

example2.rb:3: Report#rows return type could not be inferred
example2.rb:9: Unresolved return type Rows::Unknown for Report#fetch

The first message names the method, not the part of the expression responsible. The second names the underlying cause but sits at def fetch on line 9, not at the expression in rows that failed — and in a real file it can be far from it, among unrelated problems.

Solution

Both messages now carry a plain-language cause naming where inference stopped and what it was called on:

example1.rb:5: Variable type could not be inferred for v: `no_such` could not be resolved on String
example2.rb:3: Report#rows return type could not be inferred: could not determine the return type of `fetch` on Report

A name that matched no definition renders as `name` could not be resolved on Type; a definition whose declared return type will not resolve renders as could not determine the return type of `name` on Type. Messages stay byte-identical when no cause can be named, and when the failing call is the one already named.

The method-return path matters most for code with no @type tags at all, which is the common case. In the second example the return value is the bare variable ys, so the walk continues into that variable's own assignment — which is why the cause names fetch, a call that appears nowhere in the return expression itself.

Mechanism: Chain#trace re-walks the chain exactly as #define does, recording each link's receiver type, matched pin count, and inferred type; Chain#first_undefined_link returns the first failing record. Both are uncached and only invoked on the error path. Pin::BaseVariable#probe_blame and Pin::Method#probe_blame apply the walk to assignments and return nodes respectively.

Test plan: a message matrix in strong_spec asserts the complete rendered string for ten cases — four expression shapes, each in an untagged and a tagged form, plus a control asserting that correcting a misspelled method name reports nothing at all, plus a guardrail asserting the message is unchanged when only the final call fails. Six of the ten fail before the change; the other four pin behavior that must not shift. Three existing specs asserting the exact old method-return string were updated to the superset text. Two pending specs record problems found while testing: an unrelated parser gap, and a missing diagnostic for a call to a nonexistent method on an untagged local. That second case is pinned from both sides: an active spec asserts that no variable-validation message is produced today, and the pending spec asserts the diagnostic that should be reported. Full suite: 1638 examples, 5 failures, all 5 in spec/diagnostics and all 5 reproducing identically on unmodified master.

Opened as a draft. This PR was written by Claude (Anthropic's Claude Code) on behalf of @apiology.

🤖 Generated with Claude Code

https://claude.ai/code/session_01H1FEjW6nMpZrWPmeWX9miT

[apiology]

What's the actual typecheck error here? If it's related to the above line's nil check, is there an open PR or issue addressing that?

[apiology]

The actual error, from solargraph typecheck --level strong lib/solargraph/pin/base_variable.rb with only this line removed:

lib/solargraph/pin/base_variable.rb:190: Unresolved call to filename on Solargraph::Location, nil

That is not a tool limitation ��� the nil check really was missing. Pin::Base#location is typed Location, nil, and probe_blame here guarded only closure.nil? before calling location.filename. Pin::Method#probe_blame, added in this same PR, does guard it: return nil if node.nil? || method_body_node.nil? || location.nil?.

The guard is now extended to return nil if closure.nil? || location.nil?.

Measured after adding the guard: removing the @sg-ignore again still reports the identical Unresolved call to filename on Solargraph::Location, nil at that line, so the suppression is still needed and its cause is now the same return-guard narrowing gap as the line below ��� #1254. Retagged to match, in the same wording used in Pin::Method#probe_blame.

This comment was written by Claude Code on behalf of @apiology.

[apiology]

Ditto on actual error

[apiology]

lib/solargraph/pin/base_variable.rb:193: Wrong argument type for Solargraph::Source::Chain#first_undefined_link: name_pin expected Solargraph::Pin::Base, received Solargraph::Pin::Closure, nil

closure is Pin::Closure, nil and is guarded by return nil if closure.nil? at method entry, but the narrowing is not carried past the return guard ��� #1254 ("Flow-sensitive typing doesn't narrow past a raise/return-based nil guard"). No code change here; the existing tag matches the observed error.

This comment was written by Claude Code on behalf of @apiology.