Title
s

Steven Sherry

03/08/2020, 6:44 PM
Has anyone here figured out how to get jacoco to ignore inline function coverage? I’m asking here since Arrow uses inline quite a bit (and is the cause of my uncovered inline woes) and I’m sure other people in this channel have run into it. I don’t really care if it’s “scalable”, we just have arbitrary test coverage metrics in our company and I need to massage out the lack of inline function coverage of the report that ends up getting consumed by sonarqube
m

Mike

03/08/2020, 7:04 PM
I think the only way is to exclude the code.
j

Jannis

03/08/2020, 7:13 PM
Apart from
fold
functions the use of inline is quite rare isn't it? At least on arrow core most inline functions were functions that kapt extensions for functions optics generates and
fold
. Arrow used to have a lot more inline functions quite a long time ago though. What version are you on? o.O
Oh and
fix
is always
inline
as well.
s

Steven Sherry

03/08/2020, 7:19 PM
Ah yeah that may be what it is. I’m doing a bunch of validations from user input that get piped through a Validated flow that are then combined using
<http://Validated.applicative.ma|Validated.applicative.ma>p().fix()
. I omitted the arguments for brevity’s sake.
I’m on version 0.10.4 to answer one of your previous questions
j

Jannis

03/08/2020, 7:23 PM
Yeah
fix
is really pervasive right now. It is just a typecast and thus probably better to have it inline. We hope to remove it with arrow-meta as soon as possible because it is literally just boilerplate to patch a compiler weakness...
I’m on version 0.10.4 to answer one of your previous questions
Then it should really only be
fold
/
fix
and some function composition code with
inline
(and
@optics
generated code). A while ago much more of arrow was using
inline
but that lead to a few weird things regarding our
fx
blocks
s

Steven Sherry

03/08/2020, 7:25 PM
Looks like where I mostly use it is when I’m pattern matching. I may be able to remove fix and just have an else block
An initial run at it and my tests still pass
j

Jannis

03/08/2020, 7:27 PM
Pattern matching as in?
val x: Kind<ForOption, X> = Some(...)
when (x) {
  is Some -> ...
  is None -> ...
}
I mean that should work, but the compiler should hate it o.O
s

Steven Sherry

03/08/2020, 7:28 PM
It does
I found a different place where that doesn’t really work out so well
Chained another operator after fix
j

Jannis

03/08/2020, 7:30 PM
Well I pray for arrow-meta to be ready soon. The higherkind plugin will make this compile:
val x: Kind<ForOption, X> = Some(...)
val y: Option<X> = x
s

Steven Sherry

03/08/2020, 7:34 PM
Oh nice. I’ll probably just find some way to massage the jacoco report, probably through a dirty dirty hack.
👍 1
For anyone also having issues with code coverage from
fix()
, I was able to drastically improve my code coverage doing the following in my tasks block inside of my build.gradle.kts :
jacocoTestReport {
  classDirectories.setFrom(
    sourceSets.main.get()
      .output.asFileTree.matching {
        exclude("**/*inlined*.class")
    }
  )
}
❤️ 3
🙏 1
took one of my packages from 28% to 77% instruction coverage
😍 2
m

Mike

03/09/2020, 2:19 AM
Jacoco plugin also has more direct settings for exclusions so you don't have to know so much. I'd suggest looking at the docs for the plugin for the exclusions property of Jacoco configuration for a more idiomatic solution.
s

Steven Sherry

03/09/2020, 2:28 AM
I did and they didn’t do what I was looking for. Every solution that I came upon was some variation of that (albeit in groovy)
m

Mike

03/09/2020, 9:23 PM
Ahhh, yes, you're excluding class files and I was thinking from the source side. My mistake.