-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Add filter for methods that Kotlin compiler generates #689
Conversation
Constructors are ignored for tests with debug information stripped pass.
List of class annotations descriptions and source file name are added.
@goodwinnk Are generated method already without line numbers? Or what would be the minimum required Kotlin compiler version? |
Generated methods are without line numbers since Kotlin 1.0.0 till the latest one. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @goodwinnk , thanks for the great idea how to implement filtering and this well-crafted pull request. I would like to propose two formal changes. We also always add an entry to changes.html.
If you don't mind I can take care of this.
import java.util.ListIterator; | ||
import java.util.Set; | ||
|
||
public class KotlinNoSourceLinesFilter implements IFilter { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
JavaDoc missing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In addition to a missing Javadoc - maybe also rename into KotlinGeneratedFilter
by analogy with existing GroovyGeneratedFilter
and LombokGeneratedFilter
?
* @param methodNode | ||
* method to inspect | ||
* @param output | ||
* callback to report filtering results to | ||
*/ | ||
void filter(String className, String superClassName, MethodNode methodNode, | ||
void filter(String className, String superClassName, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now we're definitely beyond the limit of extra parameters. Probably we will see even more in future. I would propose to introduce a new interface
public interface org.jacoco.core.internal.analysis.filter.IFilterContext{
String getClassName();
String getSuperClassName();
Set<String> getClassAnnotations();
String getSourceFileName();
}
For now this can be directly implemented by ClassAnalyzer
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought about introducing something like IFilterContext
but decided that it's a bit more structural change than this PR needs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First of all - thank you for this nice contribution! 👍 ❤️
I added few more comments. IMO one about iteration and one about cleanup of map are worth to be addressed, others are really minor, picky as @marchof loves 😉 in order to keep our codebase healthy, clean and consistent, so feel free to leave them on his shoulders as he already requested 😜 😆
...co.core.test/src/org/jacoco/core/internal/analysis/filter/TryWithResourcesEcjFilterTest.java
Outdated
Show resolved
Hide resolved
org.jacoco.core/src/org/jacoco/core/internal/analysis/filter/KotlinNoSourceLinesFilter.java
Outdated
Show resolved
Hide resolved
org.jacoco.core/src/org/jacoco/core/internal/analysis/filter/KotlinNoSourceLinesFilter.java
Outdated
Show resolved
Hide resolved
org.jacoco.core/src/org/jacoco/core/internal/analysis/ClassAnalyzer.java
Outdated
Show resolved
Hide resolved
org.jacoco.core/src/org/jacoco/core/internal/analysis/filter/AbstractAnnotatedMethodFilter.java
Outdated
Show resolved
Hide resolved
org.jacoco.core/src/org/jacoco/core/internal/analysis/MethodAnalyzer.java
Outdated
Show resolved
Hide resolved
org.jacoco.core/src/org/jacoco/core/internal/analysis/ClassAnalyzer.java
Outdated
Show resolved
Hide resolved
org.jacoco.core/src/org/jacoco/core/internal/analysis/filter/Filters.java
Outdated
Show resolved
Hide resolved
...co.core.test/src/org/jacoco/core/internal/analysis/filter/KotlinNoSourceLinesFilterTest.java
Outdated
Show resolved
Hide resolved
import java.util.ListIterator; | ||
import java.util.Set; | ||
|
||
public class KotlinNoSourceLinesFilter implements IFilter { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In addition to a missing Javadoc - maybe also rename into KotlinGeneratedFilter
by analogy with existing GroovyGeneratedFilter
and LombokGeneratedFilter
?
* Rename Filter to KotlinGeneratedFilter in analogy to other filters. * Iterate over instructions without allocation * Identify LineNumberNode with getType() * Remove unnecessary clear() * Use project source formatting (final, imports)
@Godin I tried to address your issues in first step. I will work on my findings tonight. |
@goodwinnk Silly question from my side: Have you done some integration testing with a Kotlin project? Are the results as expected? |
@marchof, @Godin Thank you for the review. I would still like to ask you fill
I'm using the sample project https://github.com/goodwinnk/kotlin-features-coverage and have just updated readme with the results from jacoco with All results are as expected. |
@goodwinnk Thanks for the deedback! Sure, I will finalize this PR. |
@Godin I tried to address all issues . Can you please re-review? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@marchof perfect! 👍
As usual I also made end-to-end test - example.zip
Before this change using JaCoCo 0.8.1:
Results are the same for Kotlin 1.0.1
and 1.2.41
.
Noticed that val
's in data classes require read test and var
s both read and write.
This seems correct to me - don't read val
= remove it, don't write var
= make it val
. And this seems to be consistent with Groovy. However not consistent with Lombok for which we filter out generated setters and getters 😆
Hi, thanks ! |
See FAQ https://www.jacoco.org/jacoco/trunk/doc/faq.html
|
I have pointed my app at 0.8.2-SNAPSHOT. The fix is working nicely, thanks. |
@marchof I also moved to SNAPSHOT release, no issues, thanks. PS: Sorry, I should read docs first. |
The report currently doesn't look great due to JaCoCo including compiler-generated methods such as equals and hashCode. This will be fixed in the next JaCoCo release (see jacoco/jacoco#689).
Is there a configuration option that needs to be set to take advantage of this with 0.8.2? |
No - all filters so far implemented in JaCoCo are enabled unconditionally and do not require any configuration. Also by carefully reading this thread - you can find above example.zip which contains complete example for Maven and Gradle demonstrating that Please also pay attention on what is stated in each release announcement starting from 0.8.0 up to 0.8.2 and in changelog: filtering happens at a time of generation of reports, so that
while
If the above doesn't help, then please use our mailing list to provide complete example that demonstrates your problem. |
Filtering for Kotlin generated methods based on line numbers absence among method instructions.