Run inference for generic method calls nested inside receivers#1571
Conversation
|
This change is part of the following stack:
Change managed by git-spice. |
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (2)
WalkthroughThis PR changes GenericsChecks.getTreeType so MethodInvocationTree uses the call's enclosing/receiver type to recompute the invoked method's MethodType (via getEnclosingTypeForCallExpression and TypeSubstitutionUtils.memberType) before calling handler.onOverrideMethodType, instead of always using symbol.type.asMethodType(). It also adds a nestedReceivers() test exercising chained generic receiver inference under Possibly related PRs
Suggested labels
Suggested reviewers
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 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 |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #1571 +/- ##
=========================================
Coverage 88.40% 88.41%
- Complexity 2881 2882 +1
=========================================
Files 103 103
Lines 9637 9644 +7
Branches 1940 1941 +1
=========================================
+ Hits 8520 8527 +7
Misses 535 535
Partials 582 582 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
msridhar
force-pushed
the
nested-receiver-inference
branch
from
ca80da3 to
d293b16
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
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 `@nullaway/src/test/java/com/uber/nullaway/jspecify/GenericMethodTests.java`:
- Around line 1656-1657: Remove the unused import "java.util.Objects" from the
test source string in GenericMethodTests.java so the test code no longer
contains an unused import; locate the multi-line test string where the import
appears (the block containing 'import java.util.Objects;') and delete that
import line so the string only includes actually used imports.
🪄 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: 593692d6-c504-4bd6-80a0-10c1499a442e
📒 Files selected for processing (2)
nullaway/src/main/java/com/uber/nullaway/generics/GenericsChecks.javanullaway/src/test/java/com/uber/nullaway/jspecify/GenericMethodTests.java
lazaroclapp
left a comment
lazaroclapp
left a comment
There was a problem hiding this comment.
Some nits, but overall LGTM!
| static Foo<@Nullable String> FOO2 = | ||
| Foo.of(new Foo<@Nullable String>()) | ||
| .or(new Foo<@Nullable String>()) | ||
| .or(new Foo<@Nullable String>()); |
There was a problem hiding this comment.
A bit surprised we don't have an example here reporting an issue (e.g. where one of the .or(...) methods is passing an incompatible type. We have a few true negative cases, but not the true positive, right?
There was a problem hiding this comment.
Good point, will add a true positive test
| // for method invocations and field reads, there may be annotations on type variables in | ||
| // the return / field type that need to be restored | ||
| if (tree instanceof MethodInvocationTree invocationTree) { | ||
| // for a call to an instance method, we may need to run inference on a nested call |
There was a problem hiding this comment.
Is nested call here just meaning a chained method call as the receiver? Or are there more complex cases? I know is in the test, but a brief example here would be great :)
2 participants
Discovered this issue while investigating #1500. When computing the type of an invocation, we may need to run inference for a generic method call nested within its receiver in order to compute its proper type.
This change exposed a couple of other issues, which are fixed in PRs stack on top of this one. The integration test failures are expected.
Summary by CodeRabbit
Bug Fixes
Tests