Skip to content
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

Introduce AssociativeMethodInvocation check #560

Merged
merged 5 commits into from
Apr 19, 2023

Conversation

Stephan202
Copy link
Member

@Stephan202 Stephan202 commented Apr 1, 2023

❗ This PR is on top of #561. ❗

Suggested commit message:

Introduce `AssociativeMethodInvocation` check (#560)

This is in preparation for a bug checker that collapses multiple @BeforeTemplate methods into a single Refaster.anyOf method; such code changes may require flatting of nested Refaster.anyOf expressions; something taken care of by this check.

@Stephan202 Stephan202 added this to the 0.10.0 milestone Apr 1, 2023
@Stephan202 Stephan202 requested a review from rickie April 1, 2023 13:15
@github-actions
Copy link

github-actions bot commented Apr 1, 2023

Looks good. All 19 mutations in this change were killed.

class surviving killed
🎉tech.picnic.errorprone.bugpatterns.AssociativeMethodInvocation 0 19

Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed.

1 similar comment
@github-actions
Copy link

github-actions bot commented Apr 1, 2023

Looks good. All 19 mutations in this change were killed.

class surviving killed
🎉tech.picnic.errorprone.bugpatterns.AssociativeMethodInvocation 0 19

Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed.

@Stephan202 Stephan202 force-pushed the sschroevers/associative-operators branch from d99f65c to fc6263d Compare April 2, 2023 14:48
@Stephan202 Stephan202 changed the base branch from master to sschroevers/introduce-unwrap-method-invocation-utility April 2, 2023 14:49
@github-actions
Copy link

github-actions bot commented Apr 2, 2023

  • Surviving mutants in this change: 6
  • Killed mutants in this change: 34
class surviving killed
🧟tech.picnic.errorprone.bugpatterns.util.SourceCode 6 17
🎉tech.picnic.errorprone.bugpatterns.AssociativeMethodInvocation 0 17

Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed.

@rickie rickie requested a review from oxkitsune April 6, 2023 07:31
@rickie rickie force-pushed the sschroevers/introduce-unwrap-method-invocation-utility branch from c731b57 to 5ae92ab Compare April 7, 2023 12:48
Base automatically changed from sschroevers/introduce-unwrap-method-invocation-utility to master April 7, 2023 13:05
@Stephan202 Stephan202 force-pushed the sschroevers/associative-operators branch from fc6263d to 485594e Compare April 7, 2023 18:29
Copy link
Member Author

@Stephan202 Stephan202 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rebased; PR now targets master. Tnx for the review @oxkitsune 🙇

@github-actions
Copy link

github-actions bot commented Apr 7, 2023

Looks good. All 17 mutations in this change were killed.

class surviving killed
🎉tech.picnic.errorprone.bugpatterns.AssociativeMethodInvocation 0 17

Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed.

@sonarqubecloud
Copy link

sonarqubecloud bot commented Apr 8, 2023

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 2 Code Smells

No Coverage information No Coverage information
0.0% 0.0% Duplication

Copy link
Member

@rickie rickie left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a commit and some thoughts. PTAL 😄

@BugPattern(
summary =
"These methods implement an associative operation, so you can flatten the list of operands",
link = BUG_PATTERNS_BASE_URL + "AssociativeOperatorUsage",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
link = BUG_PATTERNS_BASE_URL + "AssociativeOperatorUsage",
link = BUG_PATTERNS_BASE_URL + "AssociativeMethodInvocation",

AssociativeMethodInvocation sounds like the better one indeed :).

implements MethodInvocationTreeMatcher {
private static final long serialVersionUID = 1L;
private static final Supplier<Type> ITERABLE = Suppliers.typeFromClass(Iterable.class);
private static final ImmutableList<Matcher<ExpressionTree>> ASSOCIATIVE_OPERATIONS =
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Technically speaking this could also be a ImmutableSet right? Any reason for not doing so?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not really. Perhaps because these Matchers don't implement a properly equality test anyway. But will change :)


@Override
public Description matchMethodInvocation(MethodInvocationTree tree, VisitorState state) {
for (Matcher<ExpressionTree> matcher : ASSOCIATIVE_OPERATIONS) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we start with the following if statement for fast return (tests still pass)?

    if (tree.getArguments().isEmpty()) {
      return Description.NO_MATCH;
    }

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pitest will flag it, but I agree 👍

* A {@link BugChecker} that flags unnecessarily nested usage of methods that implement an
* associative operation.
*
* <p>The arguments to such methods can be flattened without affecting semantics, while making the
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* <p>The arguments to such methods can be flattened without affecting semantics, while making the
* <p>The arguments of such methods can be flattened without affecting semantics, while making the

Why is it "to" in this context, that doesn't sound right 🤔.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know that both forms are commonly used (with "of" being more prevalent), but IMHO "to" is better here: we're passing arguments to a method, and they aren't "owned" by the method.

@AutoService(BugChecker.class)
@BugPattern(
summary =
"These methods implement an associative operation, so you can flatten the list of operands",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not really a fan of the "you" in this sentence. What about:

These methods implement an associative operation, so the list of operands can be flattened

It doesn't read as nice, but it avoids the term you 😋.

@github-actions
Copy link

Looks good. All 17 mutations in this change were killed.

class surviving killed
🎉tech.picnic.errorprone.bugpatterns.AssociativeMethodInvocation 0 17

Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed.

@Stephan202 Stephan202 force-pushed the sschroevers/associative-operators branch from 5147ccd to e5c8d06 Compare April 18, 2023 08:57
Copy link
Member Author

@Stephan202 Stephan202 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rebased and added a commit. Tnx for the review!

* A {@link BugChecker} that flags unnecessarily nested usage of methods that implement an
* associative operation.
*
* <p>The arguments to such methods can be flattened without affecting semantics, while making the
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know that both forms are commonly used (with "of" being more prevalent), but IMHO "to" is better here: we're passing arguments to a method, and they aren't "owned" by the method.

implements MethodInvocationTreeMatcher {
private static final long serialVersionUID = 1L;
private static final Supplier<Type> ITERABLE = Suppliers.typeFromClass(Iterable.class);
private static final ImmutableList<Matcher<ExpressionTree>> ASSOCIATIVE_OPERATIONS =
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not really. Perhaps because these Matchers don't implement a properly equality test anyway. But will change :)


@Override
public Description matchMethodInvocation(MethodInvocationTree tree, VisitorState state) {
for (Matcher<ExpressionTree> matcher : ASSOCIATIVE_OPERATIONS) {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pitest will flag it, but I agree 👍

@github-actions
Copy link

  • Surviving mutants in this change: 1
  • Killed mutants in this change: 19
class surviving killed
🧟tech.picnic.errorprone.bugpatterns.AssociativeMethodInvocation 1 19

Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed.

@rickie rickie merged commit ee0884e into master Apr 19, 2023
@rickie rickie deleted the sschroevers/associative-operators branch April 19, 2023 06:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

3 participants