-
Notifications
You must be signed in to change notification settings - Fork 134
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Convert multi param lambdas and local method invocations to method references #1365
Conversation
Generate changelog in
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks slick!
baseline-error-prone/src/main/java/com/palantir/baseline/errorprone/LambdaMethodReference.java
Outdated
Show resolved
Hide resolved
" return value.length();", | ||
" }", | ||
"}") | ||
.doTest(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure these negative tests are necessary when we have refactoring tests as well.
baseline-error-prone/src/main/java/com/palantir/baseline/errorprone/LambdaMethodReference.java
Outdated
Show resolved
Hide resolved
VisitorState state, | ||
boolean isLocal) { | ||
if (!symbol.isStatic() && isLocal) { | ||
return "this." + symbol.name.toString(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think there might be some oddness if the method is. It provided by this, but an enclosing class, requiring prefix “Enclosing.this.“. Worth a test to verify, I’d probably exclude that from the check rather than attempt to refactor since it’s fairly uncommon.
…ne into fo/lambda-methods
|
||
ExpressionTree receiver = ASTHelpers.getReceiver(methodInvocation); | ||
boolean isLocal = isLocal(methodInvocation); | ||
if (!isLocal && !(receiver instanceof IdentifierTree)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this prevent us from fixing static method calls? I don't think static methods have receivers (but I may be incorrect)
- value -> Preconditions.checkNotNull(value)
+ Preconditions::checkNotNull
Seeing a lot of places where we're not qualifying the method reference correctly. This results in: - open().runVoid(conn -> consumer.accept(conn));
+ open().runVoid(Consumer::accept); where we want: - open().runVoid(conn -> consumer.accept(conn));
+ open().runVoid(consumer::accept); however I think we only want to do this when |
* Fix lambdas * dont change reference capture time * avoid refactoring lambdas with param types * cyclo
<!-- User-facing outcomes this PR delivers -->
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Validated on a large internal project
👍 |
Released 3.19.0 |
Before this PR
We did not catch or convert any lambda that took multiple parameters to method references and we did not convert any local instance method either
After this PR
==COMMIT_MSG==
Convert multi param lambdas and local method invocations to method references
==COMMIT_MSG==
Possible downsides?
We want to make sure this works in all cases so we should test against our large internal repo before merging