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

compilable variants #6

Open
wants to merge 7 commits into
base: master
Choose a base branch
from
Open

compilable variants #6

wants to merge 7 commits into from

Conversation

poosomooso
Copy link
Member

also fixing things that I think might be bugs.

this is a draft (for now) mostly because I am using this to document changes I make with comments.

@@ -263,41 +263,51 @@ public void mutate(Representation<G> variant) throws GiveUpException {

Copy link
Member Author

Choose a reason for hiding this comment

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

opefully I'm not too offbase with this mutate function.... it was a very confusing time but after reading the code and messing with the code and then rereading the code, I think the old version of the code was functional in a convoluted way (I was not convinced of that statement when I started changing this mutate function).

I kinda just took a cue from what used to be line 284 (not sure if it was a todo, but it seemed like a todo).

I think the main functional difference now is that a variant will always have promut number of mutations, whereas before, some of the locations found would not work, causing mutations < promut.

//If it already picked all the fix atoms from current FixLocalization, then start picking from the ones that remain
if(proMutList.size()>=faultyAtoms.size()){
localization.setAllPossibleStmtsToFixLocalization();
alreadySetAllStmtsToFixLoc = true;
faultyAtoms = localization.getFaultLocalization();
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 sure if this was the right thing to do here. I'm not entirely sure how localization.setAllPossibleStmtsToFixLocation actually affects the fault localization; looking at the code, it seems that method affects a field called this.fixLocations or something, but the way we used to query for locations, localization.getRandomLocation, uses this.faultLocalization

alreadyOnList = proMutList.contains(wa);
} while(alreadyOnList);
proMutList.add((Location)wa);
wa = (Location) GlobalUtils.chooseOneWeighted(new ArrayList(faultyAtoms), Configuration.randomizer.nextDouble());
Copy link
Member Author

Choose a reason for hiding this comment

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

Significantly uglier; I just copied what was in localization.getRandomLocation and pasted it here except changed the list of choices to faultyAtoms; open to suggestions

@@ -241,7 +241,7 @@ public JavaEditOperation makeEdit(Mutation edit, Location dst, EditHole sources)
int atom = item.getAtom();
List<WeightedAtom> inScopeThere = this.scopeHelper(variant.instantiateLocation(atom, item.getRight()), variant, editType);
for (WeightedAtom there : inScopeThere) {
if (there.getAtom() != location.getId()) {
if (there.getAtom() == location.getId()) {
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 sure who uses SWAP but it doesn't make sense to swap statements when the location of the third expr is not the same as the original location

Comment on lines -136 to -147
//Heuristic: Swapping, Appending or Replacing a return stmt to the middle of a block will make the code after it unreachable
ASTNode parentBlock = potentiallyBuggyStmt.blockThatContainsThisStatement();
if(parentBlock != null && parentBlock instanceof Block) {
List<ASTNode> statementsInBlock = ((Block)parentBlock).statements();
ASTNode lastStmtInTheBlock = statementsInBlock.get(statementsInBlock.size()-1);
if(!lastStmtInTheBlock.equals(faultAST)){
continue;
}
} else {
continue;
}

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 just noticed that this was here before and was my initial idea; I guess the assumption of no floating blocks was not a good one


// oneday FIXME: lowercase the package name because it annoys me...
Copy link
Member Author

Choose a reason for hiding this comment

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

you're welcome

@poosomooso
Copy link
Member Author

Intellij autoformatted everything which is great but I'm so sorry if you are looking through the diffs

@poosomooso poosomooso marked this pull request as ready for review October 10, 2019 14:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant