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 ConflictDetection utility class #478

Merged
merged 4 commits into from
Feb 13, 2023

Conversation

eric-picnic
Copy link
Contributor

@eric-picnic eric-picnic commented Jan 27, 2023

Suggested commit message:

Introduce support for detecting conflicts when renaming methods (#478)

By moving reusable conflict detection code from `JUnitMethodDeclaration` to a
new `ConflictDetection` class.

@github-actions
Copy link

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

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

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 with some suggestions.

Suggested commit message;

Introduce `ConflictDetection` utility class (#478)

import java.util.Optional;

/**
* A set of helper methods for finding conflicts which would be caused by applying certain fixes.
Copy link
Member

Choose a reason for hiding this comment

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

Hmm, not a huge fan of the "certain fixes".

I'm suggesting an alternative,feel free to revert or tweak :).


/**
* A {@link BugChecker} that flags method rename blockers found by {@link
* ConflictDetection#findMethodRenameBlocker(Symbol.MethodSymbol, String, VisitorState)}.
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
* ConflictDetection#findMethodRenameBlocker(Symbol.MethodSymbol, String, VisitorState)}.
* ConflictDetection#findMethodRenameBlocker(MethodSymbol, String, VisitorState)}.

@@ -8,8 +8,8 @@
import static com.google.errorprone.matchers.Matchers.hasModifier;
import static com.google.errorprone.matchers.Matchers.not;
import static java.util.function.Predicate.not;
import static tech.picnic.errorprone.bugpatterns.util.ConflictDetection.findMethodRenameBlocker;
Copy link
Member

Choose a reason for hiding this comment

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

Let's not statically import. That may read a bit better.

@github-actions
Copy link

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

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

Copy link
Member

@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. Didn't call out all changes.

void matcher() {
CompilationTestHelper.newInstance(RenameBlockerFlagger.class, getClass())
.addSourceLines(
"/A.java",
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
"/A.java",
"A.java",

Comment on lines 25 to 27
* <li>Whether the rename would merely introduce a method overload, rather than clashing with an
* existing method declaration.
* <li>Whether the rename would cause a method in a superclass to be overridden.
Copy link
Member

Choose a reason for hiding this comment

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

We do check superclasses; let's rephrase this.

@Override
public Description matchMethod(MethodTree tree, VisitorState state) {
return ConflictDetection.findMethodRenameBlocker(
ASTHelpers.getSymbol(tree), tree.getName() + "t", state)
Copy link
Member

Choose a reason for hiding this comment

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

Clearer (or some variation hereof):

Suggested change
ASTHelpers.getSymbol(tree), tree.getName() + "t", state)
ASTHelpers.getSymbol(tree), tree.getName() + "WithSuffix", state)

Copy link
Member

Choose a reason for hiding this comment

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

Yes but then indeed the in -> int case is not tested nicely. Couldn't figure out a nicer way to do that. (Based on the changes not including this change I suspect you went through the same train of thoughts there 😉).

Copy link
Member

Choose a reason for hiding this comment

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

Exactly 😄. Forgot to remove this comment 👍

import java.util.Optional;

/** A set of helper methods for detecting conflicts that would be caused when applying fixes. */
public final class ConflictDetection {
Copy link
Member

Choose a reason for hiding this comment

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

Fine for now, but I suspect that eventually we'll want a more generic name. Time will tell :)

@github-actions
Copy link

  • Surviving mutants in this change: 1
  • Killed mutants in this change: 19
class surviving killed
🧟tech.picnic.errorprone.bugpatterns.util.ConflictDetection 1 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

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

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

@Stephan202
Copy link
Member

I see that one mutant survived; will have a look at that in a bit.

@Stephan202 Stephan202 added this to the 0.9.0 milestone Feb 12, 2023
@github-actions
Copy link

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

class surviving killed
🎉tech.picnic.errorprone.bugpatterns.util.ConflictDetection 0 20

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

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.

Changes LGTM!

@Override
public Description matchMethod(MethodTree tree, VisitorState state) {
return ConflictDetection.findMethodRenameBlocker(
ASTHelpers.getSymbol(tree), tree.getName() + "t", state)
Copy link
Member

Choose a reason for hiding this comment

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

Yes but then indeed the in -> int case is not tested nicely. Couldn't figure out a nicer way to do that. (Based on the changes not including this change I suspect you went through the same train of thoughts there 😉).

eric-picnic and others added 4 commits February 13, 2023 11:47
by moving reusable conflict detection code from `JUnitMethodDeclaration` to a
new `ConflictDetection` class.
@rickie rickie force-pushed the eric-picnic/conflict-detection branch from 0df7030 to 9dfb06b Compare February 13, 2023 10:47
@rickie
Copy link
Member

rickie commented Feb 13, 2023

Rebased, will merge once 🍏.

@github-actions
Copy link

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

class surviving killed
🎉tech.picnic.errorprone.bugpatterns.util.ConflictDetection 0 20

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

@rickie rickie changed the title Introduce support for detecting conflicts when renaming methods Introduce ConflictDetection utility class Feb 13, 2023
@rickie rickie merged commit 29469cb into master Feb 13, 2023
@rickie rickie deleted the eric-picnic/conflict-detection branch February 13, 2023 11:43
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.

None yet

3 participants