You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While performing the analyzis described in #500 I found two bug-introducing patches that could further improved, regarding the changes each patch makes to some import statements.
The current bug-introducing patch for Cli-7 adds an import statement to the buggy version and removes another import statement:
as both changes occur in non-consecutive lines of code, in the buggy version, the import java.util.HashSet; statement is considered part of the buggy behavior and the removed import java.util.LinkedHashSet; statement is considered a fault of omission.
Similar, the current bug-introducing patch for Cli-36 (OptionGroup.java file) adds an import statement to the buggy version and removes another import statement:
as both changes occur in non-consecutive lines of code, in the buggy version, the import java.util.HashMap; statement is considered part of the buggy behavior and the removed import java.util.LinkedHashMap; statement is considered a fault of omission.
I would suggest we re-order those import statements in the bug-introducing patches as
Since refactoring does not affect the behavior of the code, it is not considered part of a bug fix, and the changes introduced during refactoring should be removed from the Defects4J patch.
I wonder whether introducing a custom refactoring of import statements would somehow incentive others to perform other kind of refactors in the bug-introducing patches provided by Defects4j. Please, let me know what you think about it.
The text was updated successfully, but these errors were encountered:
Ah, interesting. I support making this change, as it more accurately reflects the actual bug (and its fix).
I wonder whether introducing a custom refactoring of import statements would somehow incentive others to perform other kind of refactors in the bug-introducing patches provided by Defects4j. Please, let me know what you think about it.
Patch minimization requires some degree of interpretation. I am certain we have made other similar "refactorings" when performing minimization. I am not bothered by a limited amount of refactoring to isolate the bug. I think the key is to emphasize that such refactoring:
Should only be in service of isolating and minimizing the bug.
Should be limited to smallest amount of change required to separate the bug from unrelated code changes.
Hi @rjust and @Greg4cr,
While performing the analyzis described in #500 I found two bug-introducing patches that could further improved, regarding the changes each patch makes to some import statements.
as both changes occur in non-consecutive lines of code, in the buggy version, the
import java.util.HashSet;
statement is considered part of the buggy behavior and the removedimport java.util.LinkedHashSet;
statement is considered a fault of omission.as both changes occur in non-consecutive lines of code, in the buggy version, the
import java.util.HashMap;
statement is considered part of the buggy behavior and the removedimport java.util.LinkedHashMap;
statement is considered a fault of omission.I would suggest we re-order those import statements in the bug-introducing patches as
and
so that those import statements are only considered buggy-related and not faults of omission (which they are not).
Extra: related to this, the current bug-introducing patch for Cli-1 could also be further improved.
The patch-minimization guide states that code refactoring should be removed from bug-introducing patches
I wonder whether introducing a custom refactoring of import statements would somehow incentive others to perform other kind of refactors in the bug-introducing patches provided by Defects4j. Please, let me know what you think about it.
The text was updated successfully, but these errors were encountered: