Skip to content
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

Allow to handle "no source root found" in a custom way #525

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

TheElectronWill
Copy link

This introduce a "PathRecoverer" that can take action when a path is not in any source root. In particular, it can replace the path and allow to continue, or skip the element, or fail (and of course emit a warning, or whatever - but I didn't want to make the reporter itself handle logging, they will look better if handled from sbt, mill, etc.)

The next step is to use this in the sbt plugin, and then we can say goodbye to the "no source root found for $x" error!

Copy link
Member

@ckipp01 ckipp01 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a lot for the pr @TheElectronWill!

So my largest concern is compat. Right now these are breaking changes to public classes. So I think we might need to rethink this.

Secondly, on the reporting side, we really need to make sure that we complain loudly when we do come across this. If not, people will hit on this and just never report upstream issues when in reality, they are probably issues in the coverage instrumentation.

sourceEncoding: Option[String]
) extends BaseReportWriter(sourceDirectories, outputDir, sourceEncoding) {
sourceEncoding: Option[String],
recoverNoSourceRoot: BaseReportWriter.PathRecoverer
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I think we'll need to handle this a bit differently. These would be breaking changes for all the reporters, meaning another major bump, and I don't think we want to do another major atm. Can we potentially switch these up to either have a default implementation for this or another way that won't break compat for existing tools that are using this?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand.
I can make the default throw an exception (i.e. keep the old behavior) and allow the "recoverer" to be added up.

Comment on lines +41 to +42
.find(root => canonicalSrc.startsWith(root))
.map(root => canonicalSrc.substring(root.length))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit, maybe personal preference so take it or leave it

Suggested change
.find(root => canonicalSrc.startsWith(root))
.map(root => canonicalSrc.substring(root.length))
.collectFirst {
case root if canonicalSrc.startsWith(root) =>
canonicalSrc.substring(root.length)
}

Copy link
Author

@TheElectronWill TheElectronWill Dec 1, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah I hesitated 😄

@TheElectronWill
Copy link
Author

TheElectronWill commented Dec 1, 2022

Secondly, on the reporting side, we really need to make sure that we complain loudly when we do come across this

How can the reporter emit a proper warning without having access to a logger? :c (or maybe it has access to something I've missed). I would like to avoid a basic println (which wouldn't be colored not formatted properly, and thus would be less likely to be seen IMO).

edit: wait, you mean the "reporting side" is actually "the sbt scoverage plugin" (and mill, gradle, etc.)? I planned to open a PR in it once this one is merged. By making the default throw an exception, and the plugins warn appropriately, it should be ok.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants