Add filter for bytecode that ECJ generates for String in switch

[Godin]

No description provided.

[Godin]

To be removed by/after #734

[Godin]

Actually this can be done during counting without need to modify instructions.

[marchof]

I wonder what exactly this method does... can you please add some JavaDoc?

[Godin]

@marchof I was about to ask your advice about how to document it based on what its implementation does 😉

Something like

	/**
	 * Marks instruction that should be considered as having branches into the
	 * given instructions during computation of coverage.
	 * 
	 * @param i
	 *            instruction to be replaced
	 * @param branches
	 *            targets of branches
	 */

?

[marchof]

Ok, so it does actually not replace the instruction but its branches. In this case I would rename the method and parameters to

replaceBranches(origin, targets)

Also maybe a second sentence can clarify the behavior: "The original target branches of the origin instruction are ignored."

[Godin]

As like before this change term "branch" is fragile - we consider that each instruction has at least one branch and will be counted as covered when at least one branch is covered:

jacoco/org.jacoco.core/src/org/jacoco/core/internal/analysis/MethodAnalyzer.java

Lines 381 to 388 in d0e461a

	final int total = i.getBranches();
	final int covered = i.getCoveredBranches();
	final ICounter instrCounter = covered == 0 ? CounterImpl.COUNTER_1_0
	: CounterImpl.COUNTER_0_1;
	final ICounter branchCounter = total > 1
	? CounterImpl.getInstance(total - covered, covered)
	: CounterImpl.COUNTER_0_0;
	coverage.increment(instrCounter, branchCounter, i.getLine());

So in some sense this replaces instruction and not just its branches:

jacoco/org.jacoco.core/src/org/jacoco/core/internal/analysis/MethodAnalyzer.java

Lines 389 to 411 in cc43220

	final int total;
	final int covered;
	final List<AbstractInsnNode> r = replacements.get(i.getNode());
	if (r != null) {
	int cb = 0;
	for (AbstractInsnNode b : r) {
	if (nodeToInstruction.get(b).getCoveredBranches() > 0) {
	cb++;
	}
	}
	total = r.size();
	covered = cb;
	} else {
	total = i.getBranches();
	covered = i.getCoveredBranches();
	}
	final ICounter instrCounter = covered == 0 ? CounterImpl.COUNTER_1_0
	: CounterImpl.COUNTER_0_1;
	final ICounter branchCounter = total > 1
	? CounterImpl.getInstance(total - covered, covered)
	: CounterImpl.COUNTER_0_0;
	coverage.increment(instrCounter, branchCounter, i.getLine());

and while we don't have use-case and don't need this, even

output.replace(original, Collections.singletonList(replacement))

works.

Thus not sure about renaming of method.
Renaming of second parameter into targets sounds good.
And for first one feel that original sounds better than origin.

---

I like the idea to add second statement 👍 with slight rewording

The original target branches of the original instruction will be ignored.

[marchof]

Well, at least in the Analyzer I used the term "branch" as a synonym for a edge in the control flow graph. But with the JavaDoc we can leave the method as is.

[Godin]

@marchof I added

• Javadoc to IFilterOutput
• tests to MethodAnalyzerTest
• changelog entry

[Godin]

Copy-paste mistake - here and below should be "b" instead of "\0a".

[marchof]

@Godin Sorry for coming back to this API again. I still think the API is confusing and can be improved:

1. "instruction to be replaced": The instruction is not replaced, only the CFG edges to its successors is replaced by new edges.
2. The targets have no order and must be unique. Should be a Set.

Here is my proposal:

    /**
     * Replaces the outgoing branches of a given instruction with new target
     * target instructions.
     *
     * @param source
     *            instruction which branches should be replaced
     * @param newTargets
     *            new targets of the branches
     */
    void replaceBranches(AbstractInsnNode source,
    		Set<AbstractInsnNode> newTargets);

I know I introduced the term "branch" again. But this is what we conistently use in the JaCoCo code base and from my point of view it simplifies the description so that the second phrase is not needed at all any more.

WDYT?

[Godin]

The targets have no order and must be unique. Should be a Set.

Actually there is order, which is IMO well defined and very important property of/in MethodAnalyzer, otherwise how merge works? 😉 In particular default of switch has number 0:

jacoco/org.jacoco.core/src/org/jacoco/core/internal/analysis/MethodAnalyzer.java

Lines 334 to 335 in 63d55ac

	int branch = 0;
	visitSwitchTarget(dflt, branch);

And so maybe List will be less confusing and more consistent even if doesn't play role in this API ?

---

The instruction is not replaced, only the CFG edges to its successors is replaced by new edges.

As we discussed earlier and as in implementation - we don't modify CFG, this affects only afterwards computation.

I know I introduced the term "branch" again.

No problem with term "branch" - it is already in Javadoc.

Right now I realized that with or without renaming of method on replaceBranches from this interface alone not clear that replacement of branches changes coverage of instruction and not just branch coverage.

---

    /**
     * Replaces the outgoing branches of a given instruction with new target

Other methods use term mark (consistency?) and state that they affect stage of computations, i.e. not the original CFG and not the propagation of probes, what again as was discussed earlier is quite important in this case. So not sure that this is cleaner/better than current

	/**
	 * Marks instruction that should be considered as having branches into the
	 * given instructions during computation of coverage.

Can imagine combination of both:

 	/**
	 * Marks instruction whose outgoing branches should be replaced during
	 * computation of coverage.
 	 * 
 	 * @param source
	 *            instruction which branches should be replaced
 	 * @param newTargets
	 *            new targets of branches
 	 */
	void replaceBranches(AbstractInsnNode source,

---

In either case to me seems that important things are missing in this documentation:

• merge is performed before ignore and replace
• ignore doesn't affect merge and targets in replace, but affects source in replace
• targets in replace are affected by merges
• replace overrides merges of source

[Godin]

@marchof as we decided by phone:

• used my proposal of "combined version" for JavaDoc
• method and parameters were renamed
• List was replaced by Set

We'll think later about other improvements of documentation.

[marchof]

Thanks for this impressive work!

Just waiting for the green build now.