Skip to content

Audit and broaden snapshot coverage of indexer behavior.#251

Draft
jasonhawkharris wants to merge 1 commit into
scip-ruby/masterfrom
jhh/update-snapshots-and-e2e-tests
Draft

Audit and broaden snapshot coverage of indexer behavior.#251
jasonhawkharris wants to merge 1 commit into
scip-ruby/masterfrom
jhh/update-snapshots-and-e2e-tests

Conversation

@jasonhawkharris

@jasonhawkharris jasonhawkharris commented Jun 3, 2026

Copy link
Copy Markdown

Broaden snapshot coverage of indexer behavior

Adds 13 new snapshot fixtures under test/scip/testdata/ to cover indexer code paths that previously had no end-to-end test:

  • generics.rb — type_member, type_template, type_parameters
  • prepend_extend.rb — prepend and user-level extend Mod (existing mixin.rb only covers include)
  • singleton_class.rb — class << self definitions and class-instance variables
  • yield_block.rb — yield and yielded block params (YieldLoadArg / LoadYieldParams / YieldParamPresent)
  • super_call.rb — explicit-arg super(...) (complementing implicit_super_arg.rb)
  • metaprog.rb — define_method, method_missing, respond_to_missing?
  • typed_ignore.rb and typed_strong.rb — sigils not previously snapshotted
  • requires_ancestor.rb — T::Helpers.requires_ancestor
  • t_helpers.rb — T.must, T.assert_type!, T.absurd, T.bind, T.type_alias
  • nested_constants.rb — 4-level constant qualifier walks in class names, ancestors, and references (exercises saveQualifierReferences recursion)
  • abstract_interface.rb — abstract!, interface!, sealed!, mixes_in_class_methods (existing singleton.rb only covers final!)
  • requires.rb — require from top-level and method bodies, plus require_relative

This PR makes no changes to indexer code. It only adds fixtures and the snapshots they produce, locking in current behavior so future regressions are caught.

Motivation

Auditing the emission paths in scip_indexer/SCIPIndexer.cc, SCIPSymbolRef.cc, and SCIPFieldResolve.cc surfaced a number of distinct code paths — entire cfg::Tag cases, symbol kinds, and Ruby DSL constructs — that emit occurrences, symbols, or relationships but had no snapshot exercising them. That left the indexer with silent failure modes: a refactor or upstream Sorbet merge could change observable output for these constructs without any test catching it. This PR closes those gaps so the snapshot suite documents what the indexer actually does for each construct.

Test plan

All 13 new fixtures pass under both ./bazel test --spawn_strategy=local //test/scip:update_ (snapshot generation) and ./bazel test //test/scip: (deterministic comparison). The full SCIP test suite (//test/scip:scip, 59 tests) passes.


class GenericBox
# ^^^^^^^^^^ definition [..] GenericBox#
extend T::Sig

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

Should T::Sig have some sort of snapshot signal?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

It should but because it's an artificial type that is part of sorbet it's fine to skip, for the time being. I assume it hasn't been supported before your changes.

FYI, in scip-ruby we currently treat super class as reference instead of inheritance relationship. This is also acceptable for now and could be fixed but only in a separate PR.

Comment on lines +6 to +11
require 'json'
#^^^^^^^ reference [..] Kernel#require().
require 'set'
#^^^^^^^ reference [..] Kernel#require().
require_relative 'non_existent_helper'
#^^^^^^^^^^^^^^^^ reference [..] Kernel#require_relative().

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

Should there be some kind of marker for 'json', 'set' and 'non_existent_helper'


module Greetable
# ^^^^^^^^^ definition [..] Greetable#
extend T::Helpers

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

Same as before, should there be a marker for T::Helpers?

Comment on lines +16 to +17
sig { abstract.returns(String) }
# ^^^^^^ reference [..] String#

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

No reference for `sig {abstract.returns}?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I'm not sure what abstract means in this context but this also feels fine.

Comment on lines +22 to +23
super(name)
# ^^^^ reference local 1$4213039946

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

should super() have a reference?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Ideally yes. But, as mentioned in another comment, inheritance relationship handling is awkward in this indexer.

Comment on lines +11 to +12
sig { params(x: T.nilable(String)).returns(Integer) }
# ^^^^^^ reference [..] String#

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

Should 'x' have a definition marker here?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Ideally yes. But it's technically defined in line 14. If the indexer hasn't been covering it before I'd leave it as is.

Comment on lines +58 to +60
else
T.absurd(x)
end

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

Seems strange that there would be no markers here.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I agree

@jasonhawkharris jasonhawkharris requested a review from jupblb June 5, 2026 13:35
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.

2 participants