Skip to content

Fix steep warnings introduced by rbs 4.1.3 - #849

Merged
sferik merged 1 commit into
httprb:mainfrom
hakanensari:fix/steep-rbs-41-warnings
Aug 16, 2026
Merged

Fix steep warnings introduced by rbs 4.1.3#849
sferik merged 1 commit into
httprb:mainfrom
hakanensari:fix/steep-rbs-41-warnings

Conversation

@lineoffligbot

Copy link
Copy Markdown
Contributor

CI resolves gems fresh on every run (Gemfile.lock is not committed). The last green run on main resolved rbs 4.0.3; runs today resolve rbs 4.1.3, which introduces 8 new warnings, so the steep job fails even on an untouched checkout of main (see #847 and #848).

Changes, net 8 insertions and 8 deletions, behavior identical:

  • Remove two # steep:ignore comments that rbs 4.1.3 flags as redundant.
  • Add four targeted # steep:ignore comments where the stricter signatures cannot be satisfied without restructuring: three .to_h { block } sites (block body vs the new Hash::_Pair expected type) and one sum(&:size) (bare Proc vs sum's optional block type).
  • Replace the to_h swap in SYMBOL_CODES with SYMBOLS.invert, and write PerOperation::KEYS as a literal hash.

Tried and rejected: .map { }.to_h (RuboCop Style/MapToHash), each_with_object (steep UnannotatedEmptyCollection, RuboCop Style/ReduceToHash), inline tuple assertions (Metrics/ClassLength).

CI does not commit Gemfile.lock, so the rbs upgrade from 4.0.3 to
4.1.3 landed unlocked and introduced eight steep warnings that fail
`rake steep` on untouched main. Fix each by category:

- rbs 4.1 now types two previously problematic calls correctly,
  turning their `# steep:ignore` comments into RedundantIgnoreComment
  warnings: drop them (Options.new, Options::Definitions#features=).

- rbs 4.1 declares the block of `Enumerable#to_h` as returning
  `Hash::_Pair[K, V]`, an interface whose `to_ary` returns a tuple.
  Steep types an array-literal block body as `Array[...]`, never a
  tuple, so every `to_h { [k, v] }` now warns. Where an equally
  simple block-free form exists, use it: `Hash#invert` for
  Status::SYMBOL_CODES and a literal hash for PerOperation::KEYS.
  Headers#to_h, Headers#deconstruct_keys, and Options#to_hash keep
  their code with a targeted `# steep:ignore` instead: block-free
  rewrites of these trip Style/MapToHash or Style/ReduceToHash, and
  multi-line tuple assertions push Headers past Metrics/ClassLength.

- Steep now types `&:size` in `CompositeIO#size` as a bare `::Proc`,
  which no longer matches `sum`'s optional block type. Keep the code
  with a targeted `# steep:ignore`, since the explicit-block form
  trips Style/SymbolProc.
@sferik
sferik requested a balanced review from Copilot August 16, 2026 21:29

This comment was marked as low quality.

@sferik sferik left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Thanks for submitting this. Do you want to rebase your other PRs after I merge so the tests turn green?

@sferik
sferik merged commit 6430df6 into httprb:main Aug 16, 2026
9 checks passed
sferik added a commit that referenced this pull request Aug 16, 2026
Follow-up to #849, which adapted the
type-check sources to rbs 4.1's stricter signatures but left the floor
at ">= 4". The two changes are not backwards compatible: under rbs
4.0.3 the current sources produce six warnings, since the four added
`# steep:ignore` comments become RedundantIgnoreComment and the two
removed ones let UnannotatedEmptyCollection resurface (Options.new and
Options::Definitions#features=).

CI always resolves the newest rbs, because Gemfile.lock is gitignored,
so it never saw this. A contributor with a lockfile resolved at 4.0.x
would get a red `rake steep` with no indication that the fix is to
update rbs. Raise the floor to the version the sources actually
require; 4.1.0 type-checks clean.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants