Add ainfer tests for a checker that declares @RelevantJavaTypes - #8176
Merged
Merged
Conversation
No existing whole-program-inference test uses a checker that restricts the Java types on which its qualifiers may be written, so nothing tests the interaction of `@RelevantJavaTypes` with inference. Add `AinferRelevanceTestChecker`, which uses the same type system and visitor as `AinferTestChecker` but lists only `CharSequence`, `int`, and `Map.Entry` as relevant. Add the `ainferRelevanceAjavaTest` Gradle task and test inputs that cover relevant types, irrelevant types, and the several ways a program can refer to a type (a nested type, a type variable that shadows a class, a type in the same package that shadows one in `java.lang`, and so on). The generation pass compares its output to `.ajava.goal` files. The validation pass alone cannot detect an annotation that inference writes on an irrelevant type, because such an annotation does not change the result of type-checking. The goal files record current behavior: inference writes annotations even on types that the checker treats as irrelevant. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Contributor
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Advanced Run ID: 📒 Files selected for processing (28)
Included review availability: Your plan provides up to 4 included reviews per hour; 2 remain after this review. 📝 WalkthroughWalkthroughAdded a relevance inference test checker and fixtures for relevant types, irrelevant types, declaration annotations, nested types, and shadowed names. Added generation and validation JUnit runners that compare generated Priority: ⬇️ Low Change: Other Merge Risk: ⚪ Minimal · up to The new relevance inference test pipeline is wired into the aggregate test task, with no actionable current-head risk identified. 🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
Full details: Docstring CoverageExplanation Docstring coverage is 20.69% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 58 functions across 16 files. (12 skipped: 12 unsupported.)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Goal files existed for only 2 of the 9 ajava files that inference generates for the ainfer-relevance tests. In particular, nothing observed the annotations that inference writes on the irrelevant types in `RelevantSubtype` (`@AinferTop char charAt(...)`) and in `RelevantTypes` (the varargs `String @AinferTop ... args` that `RelevantTypes.java` claims to test): such an annotation does not change the result of type-checking, so the validation pass cannot detect it either. Add the 7 missing goal files, and require a goal file for every generated ajava file and vice versa, so that no inference result goes unexamined. Comment the two test inputs whose goal files now record an annotation on an irrelevant type. Also: * When the goal file or the ajava file is absent, do not advise copying a file that does not exist. * Find the generated ajava files by walking the output directory, and fail with an explanation if one is in a package subdirectory, where the flat goal-file naming scheme could never match it. (Latent today: every test input is in the unnamed package.) * Drop `build/ainfer-relevance` from the directories that `ainferRelevanceGenerateAjava` deletes; nothing creates it. * Say in `AinferRelevanceTestChecker`'s Javadoc that, unlike `AinferTestChecker`, it does not use the Value Checker as a subchecker. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…er-relevance-tests
smillst
approved these changes
Sep 16, 2026
mernst
added a commit
to mernst/checker-framework
that referenced
this pull request
Sep 16, 2026
…-insert-irrelevant-3 Upstream merged the ainfer-relevance tests (typetools#8172, typetools#8176) in their pre-fix state, which records inference writing annotations on irrelevant types. Keep upstream's test infrastructure and take this branch's goal files and comments, which record the fixed behavior. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Merge before #8177.
No existing whole-program-inference test uses a checker that declares
@RelevantJavaTypes, so nothing tests the interaction of relevance with inference.This PR adds that test infrastructure, with no change to main source code:
AinferRelevanceTestCheckeruses the same type system and visitor asAinferTestChecker, but lists onlyCharSequence,int, andMap.Entryas relevant. SoStringis relevant through subtyping, and arrays are irrelevant becauseObject[].classis not listed.ainferRelevanceAjavaTestGradle task, and the generation/validation test pair that it runs.java.lang, a lexically enclosing type, and a fully-qualified name.The generation pass compares its output to
.ajava.goalfiles. That comparison is what makes these tests useful: the validation pass alone cannot detect an annotation that inference writes on an irrelevant type, because such an annotation does not change the result of type-checking. Conversely, the validation pass is what detects an annotation that inference wrongly discards, since the error that the annotation suppresses reappears.The goal files here record current behavior -- inference writes annotations even on irrelevant types. #8177 changes that behavior, and its diff to these goal files shows exactly which annotations stop being written.
🤖 Generated with Claude Code