Add filter for duplicates of finally blocks #604

Godin · 2017-10-04T20:36:27Z

Finally filter for finally, hopefully finally final version 😆

marchof · 2017-10-05T13:22:26Z

org.jacoco.core.test/src-java7/org/jacoco/core/test/filter/TryWithResourcesTest.java

@@ -44,7 +44,7 @@ public void test() {
 		// without filter next line has branches:
 		assertLine("test.close", ICounter.EMPTY);
 		assertLine("test.catch", ICounter.NOT_COVERED);
-		assertLine("test.finally", ICounter.PARTLY_COVERED);
+		assertLine("test.finally", ICounter.FULLY_COVERED);


@Godin Just out of curiosity: The new FinallyFilter now also applies to tryWithResouces?

@marchof javac translates try-with-resources into try-catch-finally, so for it for sure applies. However most likely not applies for bytecode that ecj generates for closing of resources in try-with-resources. But applies for try-with-resources with finally for both ecj and javac as this test shows. Can add more precise tests about this, but definitely would prefer to do this in a separate pull request.

@Godin Ok, makes sense. I was wondering whether our validadtion tests for filters should only use the filter under test.

@marchof we already discussed this: for start it is very good to see combined behavior - this way with low investment we observe what end-user will observe and we observe that filters correctly cooperate and do not interfere with each other in a bad way. However I agree that in long run ability to execute filters separately will be also valuable.

@Godin Sure. For I don't want to change test strategy.

marchof · 2017-10-05T13:23:38Z

org.jacoco.core.test/src/org/jacoco/core/test/filter/targets/Finally.java

+import static org.jacoco.core.test.validation.targets.Stubs.f;
+import static org.jacoco.core.test.validation.targets.Stubs.nop;
+
+public class Finally {


@Godin Can we add a nested finally here to see how it works?

@marchof done

@Godin Thanks! ✅

marchof · 2017-10-05T16:00:52Z

org.jacoco.core/src/org/jacoco/core/internal/analysis/filter/FinallyFilter.java

+
+				if (t != finallyBlock && t.start == finallyBlock.start
+						&& t.end == finallyBlock.end) {
+					final AbstractInsnNode i = next(next(t.handler));


@Godin Potential NPE? next(t.handler) could possibly return null

@marchof t.handler is a label that must have instruction after it, so next(t.handler) can't be null.

next(next(t.handler)) potentially can be null only if handler has exactly one instruction that is the last one in method, but in this case safe to call merge(size, e, null) that safely calls isSame(size, e, null) and returns.

marchof · 2017-10-05T16:02:47Z

org.jacoco.core/src/org/jacoco/core/internal/analysis/filter/FinallyFilter.java

+		} while (!(Opcodes.ALOAD == i.getOpcode()
+				&& var == ((VarInsnNode) i).var));
+		i = next(i);
+		if (Opcodes.ATHROW != i.getOpcode()) {


@Godin Potential NPE? i could be null here -- but only for invalid class files. So probably not an issue.

marchof · 2017-10-06T06:35:39Z

org.jacoco.core.test/src/org/jacoco/core/test/filter/targets/Finally.java

+		try {
+			nop();
+		} finally { // $line-alwaysCompletesAbruptly.0$
+			return; // $line-alwaysCompletesAbruptly.1$


@Godin Here I get a warning in Eclipse, maybe annotate method with @SuppressWarnings("finally")?

@marchof added this suppression, however warnings and suppressions are incredibly inconsistent in IDEs, e.g. even after addition I see warnings in this target file and in some other target files in IntelliJ. Ideally, I think, that our main code should not contain warnings and suppressions, but should be possible to write whatever in targets without bothering with warnings/suppressions.

@Godin We could simply add @SuppressWarnings("all") to our validation targets. Should work for all IDEs.

marchof · 2017-10-06T06:45:43Z

@Godin Looks like the latest update broke some tests.

marchof · 2017-10-06T07:02:28Z

org.jacoco.core/src/org/jacoco/core/internal/analysis/filter/FinallyFilter.java

+		}
+	}
+
+	private static class Matcher {


@Godin The only state in Matcher class is member inside, which is used only locally within method filter(). Therefore should be better al local variable within this method. Then the Matcher class can be removed at all. Tried this here: https://gist.github.com/marchof/5adb1930188136c3ea340ff430a2cac5

@marchof done

@Godin Thanks! ✅

marchof · 2017-10-06T07:16:17Z

org.jacoco.core.test/src/org/jacoco/core/internal/analysis/filter/FinallyFilterTest.java

+	 * </pre>
+	 */
+	@Test
+	public void should_analyze_control_flow() {


@Godin While I'm trying to wrap my mind around the filter implementation I was wondering why we need to loop over all tryCatchBlocks with the same handler. This seems to be the only test case which triggers this. Therefore I wonder whether it might make sense to add this scenario also to the validation test.

@marchof done

@Godin When I remove the two loops like this:

// for (final TryCatchBlockNode t : tryCatchBlocks) { { final TryCatchBlockNode t = finallyBlock;

the validation tests are still fully green (ECJ) and a different test fails for javac:

emptyCatch(org.jacoco.core.test.filter.FinallyTest): Status in line 79: nop("finally"); // $line-emptyCatch.1$ expected:<[FUL]LY_COVERED> but was:<[PART]LY_COVERED>

But new test twoRegions() stays green. What am I missing here?

@marchof after this modification of both loops

emptyCatch fails because condition of if statement in second loop always false

unit test for the case of twoRegions shows that merged too much, but validation test has assertion only for final, for same reason ecj stays green

Missing assertions added.

Also this test demonstrates https://bugs.openjdk.java.net/browse/JDK-7008643

marchof · 2017-10-06T07:21:37Z

org.jacoco.core.test/src/org/jacoco/core/test/filter/targets/Finally.java

+		try {
+			nop("try");
+		} catch (Exception e) { // $line-catchNotExecuted$
+			nop("catch");


@Godin Add assertion that this line is NOT_COVERED? To ensure that no finally code sneaks in here.

@marchof done

@Godin Thanks! ✅

Godin · 2017-10-06T08:11:46Z

@marchof

Looks like the latest update broke some tests.

Ouch, forgot to update test that studies placement of GOTOs. Fixed.

marchof · 2017-10-06T09:36:40Z

org.jacoco.core.test/src/org/jacoco/core/test/validation/ExceptionsTest.java

-	private static final boolean isJDK8u152;
-
-	static {
-		final Matcher m = Pattern.compile("1\\.8\\.0_(\\d++)(-ea)?")


@Godin Deletion leads to unused imports warning for java.util.regex.*.

@marchof fixed

@Godin Thx! ✅

marchof · 2017-10-06T09:38:25Z

org.jacoco.core.test/src/org/jacoco/core/internal/analysis/filter/FinallyFilterTest.java

+	private Set<Integer> toIndexes(Set<AbstractInsnNode> set) {
+		final Set<Integer> result = new HashSet<Integer>();
+		for (final AbstractInsnNode i : set) {
+			result.add(m.instructions.indexOf(i));


@Godin Eclipse shows a boxing warning here.

@marchof if replaced by Integer.valueOf(m.instructions.indexOf(i))), then no warning in Eclipse, but warning in IntelliJ with suggestion to remove unnecessary boxing, so added @SuppressWarnings("boxing") to this method

@Godin Ok. But should give you many warnings at other places then in IntelliJ? ✅

@marchof yes, I have quite some warnings in other places in IntelliJ, but we can put this aside

marchof

@Godin Loods good to me know from a formal point of view! However I had a very hard time to understand the implementation.

Maybe the class comment can contain the description of the basic structures created by finally and our merge/ignore merge strategy.

Also maybe some inline comments, like:

why looping over all handlers with same target?
what exactly does the large while/switch block?

Godin · 2017-12-16T21:43:57Z

@marchof description and comments added, could you please re-review? If all fine, I'll squash and merge.

marchof

Thanks @Godin for the great explanation!

Godin added the component: core.filters label Oct 4, 2017

Godin added this to the 0.8.0 milestone Oct 4, 2017

Godin self-assigned this Oct 4, 2017

Godin added the type: enhancement label Oct 4, 2017

Godin added this to IN PROGRESS in Filtering Oct 4, 2017

Godin added this to IN PROGRESS in Current work items Oct 4, 2017

Godin force-pushed the issue-604 branch 2 times, most recently from fb9d8d7 to d426e84 Compare October 4, 2017 20:40

Godin requested a review from marchof October 4, 2017 20:56

marchof reviewed Oct 5, 2017

View reviewed changes

Godin force-pushed the issue-604 branch from d426e84 to 2e6a09b Compare October 6, 2017 00:15

marchof reviewed Oct 6, 2017

View reviewed changes

Godin force-pushed the issue-604 branch from 2e6a09b to 94c36a3 Compare October 6, 2017 08:11

Godin force-pushed the issue-604 branch 4 times, most recently from e79a4f7 to 2449e7d Compare October 6, 2017 09:08

marchof reviewed Oct 6, 2017

View reviewed changes

Godin force-pushed the issue-604 branch from 2449e7d to 39795cb Compare October 6, 2017 21:09

Add filter for duplicates of finally blocks

39795cb

marchof approved these changes Oct 7, 2017

View reviewed changes

Godin added 2 commits December 12, 2017 22:00

Merge branch 'master' into issue-604

6f9d91e

Add comments

ea6bb6b

marchof approved these changes Dec 19, 2017

View reviewed changes

Godin merged commit ff00194 into master Dec 19, 2017

Godin deleted the issue-604 branch December 19, 2017 22:58

Godin moved this from IN PROGRESS to DONE in Filtering Dec 20, 2017

Godin removed this from IN PROGRESS in Current work items Dec 20, 2017

jacoco locked as resolved and limited conversation to collaborators Jan 11, 2018

Godin added the language: Java label Oct 12, 2023

Add filter for duplicates of finally blocks #604

Add filter for duplicates of finally blocks #604

Conversation

Godin commented Oct 4, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

marchof Oct 6, 2017 • edited

Choose a reason for hiding this comment

marchof commented Oct 6, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Godin commented Oct 6, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

marchof left a comment

Choose a reason for hiding this comment

Godin commented Dec 16, 2017

marchof left a comment

Choose a reason for hiding this comment

marchof Oct 6, 2017 •

edited