Update a parameter's flow-sensitive type after reassignment to a non-literal type

[apiology]

Summary

Pin::Parameter#typify always returned the declared @param type once available, without ever consulting the types of the parameter's reassignments. Reassigning a parameter to the result of a call that narrows its type (e.g. a union normalized down to one member) was silently ignored, so later uses kept the stale declared type and got flagged against branches of the original union that could no longer occur.

# @param position [Position, Array(Integer, Integer)]
def describe(position)
  position = PositionNormalizer.normalize(position)
  # `position` was still typed as `Position, Array(Integer, Integer)` here,
  # even though it was just reassigned to the return value of `normalize`,
  # which is declared `@return [Position]`.
  position.line
end

Fix

Added a definite flag to Pin::BaseVariable, set by node processors based on a new Region#conditional flag — true only when an assignment is guaranteed to have executed (not inside if/unless/while/until/when/rescue/block body/&&/||/||=). Pin::Parameter#typify now tries probe (which infers from assignments) first when definite, falling back to the declared type otherwise — matching the existing union semantics that plain local variables already had for conditional reassignment.

Default-value assignments (def foo(x = 1)) are marked non-definite since they only apply conditionally (when the caller omits the arg).

Net diff on real call sites

Two of the @sg-ignore flow sensitive typing should be able to handle redefinition comments named in #1250 are now unneeded and removed (lib/solargraph/range.rb#contain?/#include?, one in lib/solargraph/api_map.rb#super_and_sub?). A handful of newly-surfaced gaps from multiple sequential unconditional reassignments (which still union rather than dominate by recency) got matching @sg-ignores, consistent with the existing convention — net zero change in solargraph typecheck --level strong problem count (584 before and after).

Test plan

• bundle exec rspec — 1626 examples, 0 failures
• SOLARGRAPH_ASSERTS=on bundle exec solargraph typecheck --level strong — same problem count as master (584)
• bundle exec rubocop clean on touched files
• Added a positive spec reproducing Flow-sensitive typing doesn't update a variable's type after reassignment to a different (non-literal) type #1250's exact repro
• Added a negative spec confirming a reassignment inside a block does not falsely narrow

Fixes #1250

🤖 Generated with Claude Code

https://claude.ai/code/session_01VHyn8dc8oSqcQJrXFgDWUo

---

Follow-up: nil-guarded default narrowed after the conditional

The dominance case above is fixed, but a neighbouring shape still failed ��� a modifier-if guarded by the variable's own nilness, where the use site is after the conditional. There it is the guard's condition, not dominance, that establishes the type on the path where the assignment did not run:

# @param tasks [Array<String>, nil]
# @return [void]
def guarded_default(tasks)
  tasks = ['a'] if tasks.nil?
  tasks.each { |t| puts t }   # was: Unresolved call to each on Array<String>, nil
end

At the merge point, path (a) ��� clause ran, new value assigned ��� was already handled by unioning in the assignment pin. Path (b) ��� clause did not run, original value survives ��� was never narrowed by the guard's condition, so Array<String>, nil was unioned back in unchanged. process_if now also asserts the opposite branch's condition facts over the rest of the enclosing compound statement, restricted to the variables the clause definitely reassigns. That restriction is the soundness lever: facts are filtered by variable name, driven by a second FlowSensitiveTyping over the same locals/ivars with restricted_names: set. Reusing process_expression inherits &&/||/! handling, including and's refusal to propagate false-facts. Only unconditional lvasgn/ivasgn count as "definitely reassigns" ��� nested conditionals and ||= are excluded.

Fixed for the modifier if, non-modifier if, unless modifier, and else-clause forms. Negative controls, all still correctly reporting (nil is not eliminated unconditionally):

tasks = ['a'] if flag              -> Unresolved call to each on Array<String>, nil
puts 'hi' if tasks.nil?            -> Unresolved call to each on Array<String>, nil
xs = [] if xs.nil? || ys.nil?      -> ys.each still errors (xs.each narrows)
if tasks.nil?; tasks = [] if flag; end -> still errors

• bundle exec rspec ��� 1646 examples, 0 failures, 57 pending
• 8 new examples in spec/type_checker/levels/strong_spec.rb; the existing dominance spec at strong_spec.rb:942 still passes
• bundle exec rubocop clean on touched files

[apiology]

🤖 Posted by Claude, not the account owner — acting on their behalf via their GitHub credentials.

Regression from this PR: reassigning a variable to a different type based on its own old value (x = x.length) applies the new type to the RHS's reference to the old value, on the same statement.

class Repro
  # @param x [String]
  # @return [void]
  def foo(x)
    x = x.length
  end
end

$ solargraph typecheck --level strong repro.rb
repro.rb:5: Unresolved call to length on Integer

x.length is String#length, evaluated against the old String-typed x — but it resolves against Integer, the type of the value being assigned on this same line. No @type tag needed.

Bisected: clean checkout at 368b3e0a (commit before this PR) — 0 problems. At b6eea57c (this PR merged) — reproduces every time.

[apiology]

🤖 Filed by Claude, not Vince — acting on his behalf via his GitHub credentials.

This fixes reassignment-type tracking for parameters, but the same gap remains for plain local variables and instance variables. The definite flag this PR adds to Pin::BaseVariable, and the region-conditional plumbing that sets it, already runs through lvasgn_node.rb and ivar assignment — so the infrastructure covers locals and ivars. What's missing is the consuming side: definite's override-over-union behavior is only wired into Pin::Parameter#typify; Pin::LocalVariable and Pin::InstanceVariable have no typify override at all, so they fall back to the un-narrowed default regardless of definite.

# @return [void]
def run
  local = 5
  local = 'hello'
  local.upcase
  nil
end

$ bundle exec solargraph typecheck --level strong repro.rb
repro.rb:5: Unresolved call to upcase

Swapping local for an @ivar (assigned in initialize, reassigned in the method) reproduces the identical error.

[apiology]

🤖 Filed by Claude, not Vince — acting on his behalf via his GitHub credentials.

Pushed ce7332967: BaseVariable#combine_assignments now drops an earlier assignment in favor of a later same-closure definite reassignment instead of unioning them (with a guard for self-referential reassignments like x = x.foo, since resolving those needs the prior assignment as a base case). This fixes locals and same-method ivar reassignment; it does not reach the cross-method ivar case (initialize + another method), since ivasgn_node.rb never sets presence:/definite: on ivar pins - a larger, separate change. Three specs that were already asserting this behavior under 'sequential assignment support' are un-pended, plus a new spec; full suite is green (1629 examples, 0 failures) with no new self-typecheck problems.

# @return [void]
def run
  local = 5
  local = 'hello'
  local.upcase  # was: Unresolved call to upcase on Integer, String
  nil
end

[apiology]

Claude: This regresses local/instance variable inference to undefined. Reduced to one mechanism (an earlier draft of this comment described what looked like two separate patterns - a while-loop case and a begin/ensure case - but neither the loop, the begin block, nor ensure turned out to be load-bearing; both collapse to this):

def m
  x = nil
  x = 1
  if x
    y = x * 2 # infers `Integer` on the parent commit, `undefined` here
  end
end

While resolving x's visibility at the if x guard, combine_assignments/override_assignments? get invoked twice: once correctly unioning x's two assignments (nil and 1), then a second time re-merging the same original x = nil declaration pin against the already-merged result. That second call is definite: true, same closure, and doesn't reference x by name, so override_assignments? treats it as a genuine supersede and replaces the accumulated [nil, 1] with just [nil] again - dropping the branch that actually executes.

[apiology]

Claude: A common pattern is guarding a nilable value and then, in the same ||-combined boolean expression, comparing that same variable — then coercing the whole thing to a real boolean with !! for a predicate method's declared Boolean return. That combination stopped resolving on this branch: the method's return type can no longer be inferred, even though Boolean is exactly what the expression evaluates to.

# typecheck --level strong

# @param val [Integer, nil]
# @return [Boolean]
def check?(val)
  !!(val.nil? || val < 5)
end

# #check? return type could not be inferred

Reduced from real code: removing !!, removing the ||, using a non-nilable param, or guarding/comparing two different variables instead of the same one each independently clear the error — only the full combination (nilable var, guarded and compared via ||, then !!-coerced) triggers it.

[apiology]

Claude: Written by Claude and posted using @apiology's GitHub credentials.

Reassignment to a non-literal type resolves correctly on this branch when it happens unconditionally. It still fails when the reassignment is inside a conditional — definite looks like it's judged for the whole closure, so a branch's own assignment doesn't take precedence over an earlier one from the enclosing scope, even at a use site on the next line.

# @param str [String]
# @param num [Integer]
# @return [void]
def unconditional_reassign(str, num)
  local = num
  local = str
  local.upcase
end

# @param str [String]
# @param num [Integer]
# @param flag [Boolean]
# @return [void]
def conditional_reassign(str, num, flag)
  local = num
  if flag
    local = str
    local.upcase
  end
end

$ solargraph typecheck --level strong repro.rb
repro.rb:20: Unresolved call to upcase
1 problem found.

Same failure with literal values in place of the parameters, and a first assignment or a same-type reassignment inside a conditional is fine — so it's specific to a type-changing reassignment inside a branch, which is where the override would need to drop the outer assignment. Verified on apiology/solargraph@0653590d4, which contains this PR's head a3ec7bab0.

[apiology]

The dominance case from my earlier comment is fixed on this branch. A neighbouring shape still fails: a modifier-if guarded by the variable's own nilness, where the use site is after the conditional rather than inside it. Here it is the guard's condition, not dominance, that establishes the type on the path where the assignment did not run.

# Fixed here -- use site inside the branch, dominated by the assignment
# @param str [String]
# @param num [Integer]
# @param flag [Boolean]
# @return [void]
def conditional_reassign(str, num, flag)
  local = num
  if flag
    local = str
    local.upcase
  end
end

# Still failing -- use site after the conditional
# @param tasks [Array<String>, nil]
# @return [void]
def guarded_default(tasks)
  tasks = ['a'] if tasks.nil?
  tasks.each { |t| puts t }
end

$ solargraph typecheck --level strong probe.rb
probe.rb:22: Unresolved call to each on Array<String>, nil
1 problem found.

Verified on apiology/solargraph@bd9fb82cb, which contains this PR's head 9fe7637c1 (behind_by=0). This is the standard Ruby default-argument idiom and accounts for 7 ignore markers in one downstream codebase.

Written by Claude and posted using @apiology's GitHub credentials.