-
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
Fix #2812 #2814
base: develop
Are you sure you want to change the base?
Fix #2812 #2814
Conversation
Thanks for your interest in palantir/gradle-baseline, @nakulj! Before we can accept your pull request, you need to sign our contributor license agreement - just visit https://cla.palantir.com/ and follow the instructions. Once you sign, I'll automatically update this pull request. |
Generate changelog in
|
27b17b2
to
8ada3c1
Compare
.prefixWith(tree, "(") | ||
.postfixWith(tree, ")") |
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 don't think it's desirable to unconditionally wrap the suggested fix with parenthesis. This will result in unidiomatic code in the common case.
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.
Do you have any suggestions on how to check if the parens are necessary?
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.
Sorry, I don't have any suggestions. I suspect this is fairly non-trivial.
I'm not sure it's worthwhile to fix this issue - I imagine it would significantly complicated the logic here.
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.
Yeah, it seems pretty hard.
That said it seems to me that unidiomatic code is preferable to incorrect code- which is what the fixer currently suggests, especially since UnnecessaryParentheses will automatically catch and fix the unidiomatic generated code.
Before this PR
Tests miss the case when a method is called on the built string, see #2812
After this PR
Parens are now surround the append result, ensuring that the post-build method call is applied to the entire built string, not just the last element.
Possible downsides?
Adds parens even when unnecessary. These can be caught and fixed by UnnecessaryParentheses, but ideally they'd only be added if necessary.