Has anyone here figured out how to get jacoco to ignore inline function coverage? I’m asking here si...

# arrow

[Steven Sherry]

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

[Mike]

I think the only way is to exclude the code.

[Jannis]

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

[Jannis]

Oh and fix is always inline as well.

[Steven Sherry]

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.

[Steven Sherry]

I’m on version 0.10.4 to answer one of your previous questions

[Jannis]

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...

[Jannis]

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

[Steven Sherry]

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

[Steven Sherry]

An initial run at it and my tests still pass

[Jannis]

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

[Steven Sherry]

It does

[Steven Sherry]

I found a different place where that doesn’t really work out so well

[Steven Sherry]

Chained another operator after fix

[Jannis]

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

[Steven Sherry]

Oh nice. I’ll probably just find some way to massage the jacoco report, probably through a dirty dirty hack.

[Steven Sherry]

took one of my packages from 28% to 77% instruction coverage

[Mike]

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.

[Steven Sherry]

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)

[Mike]

Ahhh, yes, you're excluding class files and I was thinking from the source side. My mistake.

[Tonis Ives]

@Steven Sherry this works. I want to add to it that to get it working with Optics, you need to use

exclude("**/*__Optics*.class")
You should look into your build directory and find the .class extension you want to ignore.