Any plans for a Dotty/Scala3 version of scoverage?

[gzoller]

Scoverage is the de-facto coverage tool for the Scala ecosystem. Sure sbt-jacoco exists, and I even managed to coerce it to work with Dotty, but operating just on class files does not yield ideal results. scoverage has always done very well.

Regaining scoverage as a key piece of Scala 3 ecosystem would be huge, as for now there really is nothing else.

Any plans?

[sksamuel]

Something I will investigate now that Scala 3 has been gone into feature freeze.
https://dotty.epfl.ch/blog/2020/11/09/scala3-m1.html

[gregghz]

Any update? Scala 3 is in RC1 now.

[rolandtritsch]

This seems to be covered by this PR - xebia-functional/fetch#443

[smarter]

A prototype code coverage implementation for Dotty was implemented in a fork of the compiler a few years ago with promising results: the report is at http://guillaume.martres.me/code_coverage.pdf, the code at https://github.com/Qjaquier/dotty/tree/coverage with an example usage at https://github.com/Qjaquier/dotty-coverage-tools. I think it'd be great to get this merged into the compiler but we need a volunteer to rebase and complete the prototype.

[ironfish]

Any update on when this will be addressed?

[ckipp01]

I think it'd be great to get this merged into the compiler but we need a volunteer to rebase and complete the prototype.

@smarter if someone was to grab this, would the goal be to still have this as a standalone compiler plugin, or does what you wrote imply that there'd be a desire to have actually in the compiler?

[smarter]

I think it'd be great to have this built into the compiler under a flag yes.

[mdedetrich]

@smarter Is there a reason why its being integrated straight into the compiler rather than a plugin? To me it seems like having it as a plugin is more ideal since

1. You don't "bloat" the Scala3 compiler so it doesn't end up containing everything including the kitchen sink
2. Improvements to scoverage are now tied to Scala3 lifecycle/releases where as if its a plugin, incremental improvements can be made separately from the plugin

Just my 2 cents, not sure if there is more context behind including in the actual compiler itself.

[smarter]

• Compiler plugins need to be re-published for every compiler release since the API/ABI isn't stable, and every project that uses a compiler plugin has to wait for this to happen before they can upgrade the version of Scala they use, this already wasn't great in the Scala 2 days and it will be worse in Scala 3 now that we release a new version every six weeks, it also impedes the use of RCs and nightlies.
• If anything changes in the compiler AST representation, the coverage phase will have to be updated which will require some work, if it's in a compiler plugin that means it will take even longer for it to be available after a compiler release.
• If you look at https://github.com/Qjaquier/dotty/commits/coverage you'll see that it doesn't add much code to the compiler itself, it's mostly one self-contained compiler phase. And all the tooling around coverage like the way it generates html and the sbt integration can still be maintained in a separate repo.

[mdedetrich]

Thanks for the answer, didn't realize that Scala3 is expected to release so frequently. In this case then yes, it does make sense indeed.