Fix crash cause by type inference treats java type as covariant when on the qualifier should be.#7707
Conversation
|
ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (5)
📝 WalkthroughWalkthroughThis PR changes Typing.reduceContained to always create TYPE_EQUALITY while preserving an isCovarTypeArg flag, short-circuits DefaultTypeHierarchy.visitTypeArgs for class underlying types, and adds/updates tests (CovariantError, Issue7676, Issue7695, Issue7699, Issue1098 variants, Issue1218) exercising Optional.flatMap, switch/ternary, covariance, and nullness suppression diagnostics. Possibly related PRs
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Tip 💬 Introducing Slack Agent: The best way for teams to turn conversations into code.Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.
Built for teams:
One agent for your entire SDLC. Right inside Slack. 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 |
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
framework/src/main/java/org/checkerframework/framework/util/typeinference8/constraint/Typing.java (1)
47-95:⚠️ Potential issue | 🟡 Minor | ⚡ Quick win
isCovarTypeArgis read but logically unused — should befinaland either included inequals/hashCodeor removed.The field is assigned only in the constructor (line 94) and read at line 317 to propagate into chained constraints, but
equals/hashCode(lines 467–490) ignore it. This means twoTypinginstances differing only byisCovarTypeArgare considered equal, causing silent dedup losses if both are added to a set. Since the field has no getter and plays no role in constraint reduction logic, it currently functions as dead code being carried through constraint chains.If this is an intentional placeholder for the TODO at lines 310–316, document it explicitly; otherwise, decide whether to:
- Include
isCovarTypeArginequalsandhashCode, or- Remove the field until it has an actual consumer.
Also:
- Make the field
final(only assigned in the constructor).- Fix typo at line 315: "postives" → "positives".
♻️ Suggested local tightening
- /** True if this constraint is for a covariant type argument. */ - private boolean isCovarTypeArg; + /** True if this constraint is for a covariant type argument. */ + private final boolean isCovarTypeArg;🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@framework/src/main/java/org/checkerframework/framework/util/typeinference8/constraint/Typing.java` around lines 47 - 95, The private field isCovarTypeArg is assigned only in the Typing(Constraint, AbstractType, AbstractType, Kind, boolean) constructor but is not final and is omitted from equals(Object) and hashCode(), causing logical inequality errors or silent dedup; either make isCovarTypeArg final and include it in Typing.equals and Typing.hashCode (so instances that differ only by this flag are distinct), or drop the field entirely if unused; also correct the "postives" typo to "positives" in the related comment. Ensure you update references where chained constraints propagate isCovarTypeArg (so code uses the chosen approach consistently).
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@checker/tests/tainting/CovariantError.java`:
- Around line 11-15: Update the TODO in method use(CovariantError t) to track
this known false positive by adding a linked issue reference: change the
existing comment above the cls(this.getMyClass(), t) call to include the issue
number or URL (and optionally a short title) so future work on Typing.java
(covariant qualifier handling / equal Java types) can trace this regression;
ensure the comment mentions it's a known false positive and references the
tracker ID or link.
In
`@framework/src/main/java/org/checkerframework/framework/util/typeinference8/constraint/Typing.java`:
- Around line 310-317: Fix the typo "postives" → "positives" in the comment and
add a one-line clarifying note next to the Typing constructor call (the line
that returns new Typing(this, S, T, Kind.TYPE_EQUALITY, isCovarTypeArg)) stating
that although isCovarTypeArg is being forwarded here, reduceEquality() does not
branch on that flag today so the flag has no effect; reference the Typing
constructor, the isCovarTypeArg parameter, and reduceEquality() in the note so
future readers know covariance isn't honored downstream.
---
Outside diff comments:
In
`@framework/src/main/java/org/checkerframework/framework/util/typeinference8/constraint/Typing.java`:
- Around line 47-95: The private field isCovarTypeArg is assigned only in the
Typing(Constraint, AbstractType, AbstractType, Kind, boolean) constructor but is
not final and is omitted from equals(Object) and hashCode(), causing logical
inequality errors or silent dedup; either make isCovarTypeArg final and include
it in Typing.equals and Typing.hashCode (so instances that differ only by this
flag are distinct), or drop the field entirely if unused; also correct the
"postives" typo to "positives" in the related comment. Ensure you update
references where chained constraints propagate isCovarTypeArg (so code uses the
chosen approach consistently).
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 8415384b-514c-41a4-ac37-8a1f90aa4be1
📒 Files selected for processing (7)
checker/tests/nullness/java8/Issue1098.javachecker/tests/nullness/java8/Issue1098NoJdk.javachecker/tests/tainting/CovariantError.javaframework/src/main/java/org/checkerframework/framework/util/typeinference8/constraint/Typing.javaframework/tests/all-systems/Issue7676.javaframework/tests/all-systems/Issue7695.javaframework/tests/all-systems/Issue7699.java
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@framework/src/main/java/org/checkerframework/framework/type/DefaultTypeHierarchy.java`:
- Around line 580-582: The early-return in DefaultTypeHierarchy that checks
TypesUtils.isClassType(subtype.getUnderlyingType()) wrongly skips type-argument
and raw-type logic for all declared class types; tighten this by either (A)
narrowing the guard to only java.lang.Class<X> (e.g., check the underlying
type’s symbol is java.lang.Class) so type-argument containment,
castedAsSuper(...) and the ignoreRawTypes && (subtypeRaw || supertypeRaw)
handling still run for other classes, or (B) if the broad bypass is intentional,
add a clear comment above the guard that references the root cause (e.g., the
AsSuperVisitor/JDK-8265255 issue) and explain why skipping castedAsSuper and
raw-type checks is safe; update DefaultTypeHierarchy around the isClassType
check and ensure castedAsSuper and ignoreRawTypes logic are not accidentally
bypassed for non-java.lang.Class types.
In `@framework/tests/all-systems/Issue7699.java`:
- Line 4: Fix the typo in the inline comment on the suppression annotation:
change the comment text in the line containing `@SuppressWarnings`("argument") //
TODO: This is a false postive. to read "false positive" instead of "false
postive" so the comment becomes // TODO: This is a false positive.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 4a229799-822c-493d-9ae7-5141afa51eed
📒 Files selected for processing (3)
framework/src/main/java/org/checkerframework/framework/type/DefaultTypeHierarchy.javaframework/src/main/java/org/checkerframework/framework/util/typeinference8/constraint/Typing.javaframework/tests/all-systems/Issue7699.java
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@framework/tests/value/Issue1218.java`:
- Around line 127-130: The expected-error directives before the ForEnum test
cases are malformed with an extra closing bracket (`]]`); locate the two
directives that precede the `new ForEnum<>(MyEnum.A, MyEnum.B);` and `new
ForEnum<>(MyEnum.A, MyEnum.B, MyEnum.C);` lines and change `// :: error:
[type.arguments.not.inferred]]` to `// :: error: [type.arguments.not.inferred]`
so the diagnostic matcher can correctly recognize the expected errors.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 4aa4982c-101f-4402-b095-846ed6dede04
📒 Files selected for processing (2)
framework/src/main/java/org/checkerframework/framework/type/DefaultTypeHierarchy.javaframework/tests/value/Issue1218.java
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@framework/tests/h1h2checker/GetClassStubTest.java`:
- Around line 15-19: The TODO that silences the expected assignment errors for
Class<@H1Bot ? extends `@H1Bot` Object> fail1 and Class<@H1Bot ?> fail2 should be
linked to a tracking issue and the variable names updated to reflect known false
negatives; update the comment from a bare "TODO" to include the issue number
(e.g. TODO: ISSUE-1234) adjacent to the existing "// :: error: [assignment]"
marker and rename the variables (fail1, fail2) to explicit names like
knownFalseNegative1 and knownFalseNegative2 where the declarations use
i.getClass() so the test clearly records the exception as tracked and
intentional.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 907ae580-4767-47ee-903f-e19972f4cc78
📒 Files selected for processing (4)
framework/src/main/java/org/checkerframework/common/value/ValueQualifierHierarchy.javaframework/tests/all-systems/Issue7695.javaframework/tests/all-systems/Issue7699.javaframework/tests/h1h2checker/GetClassStubTest.java
💤 Files with no reviewable changes (1)
- framework/src/main/java/org/checkerframework/common/value/ValueQualifierHierarchy.java
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
This pull request cause new false positives for classes that use
@Covariant. (OptionalandClassare the most used one in the JDK.)Fixes #7676, Fixes #7695, and Fixes #7699.