-
Notifications
You must be signed in to change notification settings - Fork 386
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
Coverlet fails to instrument F# projects that have "unknown" source (inline functions, anonymous records etc) #1145
Comments
Do you use type providers in the F# projects? There's been issues with the similar concept of source generators in C#, and it might be that the |
Yeah, there is a type provider in there. I will try to isolate it and exclude it and see if the problem goes away. Is there perhaps a known workaround for this? |
For C# code generators it seems a de facto standard is emerging that generated code should have the suffix |
Thanks for the feedback but I don't think f# generate any files when tp are
involved. It's more of an dev time VS runtime types on demand if I've
understood it right.
http://blog.mavnn.co.uk/type-providers-from-the-ground-up/
Now that I understand this I think a workaround might be to just mark all
functions that depend on any type provider type. I'll try it out on Monday.
My semi educated guess is that when coverlet try to instrument any type
provider generated code there is no reference to any source file hence the
"unknown" file reference. If coverlet was to be modified I guess it could
simply ignore symbols that doesn't have a source file reference or have an
option to do that. All this assume I'm right about how tp works tho.
Thanks, Daniel
Den fre 16 apr. 2021 17:35Peter Liljenberg ***@***.***> skrev:
… For C# code generators it seems a de facto standard is emerging that
generated code should have the suffix .g.cs, which Coverlet filters on to
ignore those files. If there is a similar standard for F# type providers,
we can add a filter on that too. I don't think there is a workaround you
can do outside of a coverlet change, however.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1145 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABD23KS4JI57BZYJV3OYCLTJBKK7ANCNFSM43A64PTQ>
.
|
@da9l that
Coverlet by design instruments only asm for which it has got a source file available. Seems that there is an |
Not yet but I think I might be able to. |
I've created a sample project that use an XMLType provider and I'm unable to recreate the problem. |
Ah... I have good reasons to think the TypeProvider was not involved at all here. For reference:
So if the unknown file reference occurs whenever one uses a f# inline function by design (inline is a #f language keyword) this should be handled by coverlet. So it's probably not a bug in the FSharpPlus lib. More likely its is either by design in the f# compiler or a bug in the f# compiler. |
As I understand the purpose of this heuristic is to filter out dependent libraries, so that the user doesn't have to exclude them manually from the code coverage. But is seems a bit too aggressive to fail if any source file is missing, rather than just failing if all source files are missing. What do you think, @MarcoRossignoli ? Alternatively, a way to identify and ignore these compiler generated files (of all kinds) without having to encode every possible file pattern might be to look if the purported path is in a subdirectory of a project file (though then we need to identify all possible project file extensions). |
Ok, I might have stumbled upon a more obvious case. I will post a repo with the problem reproduced if I succeed with that. When I use an Anonymous Record in F# this problem appears again. The type refers to the "unknown" file again. I will try to create a repo that reproduce this error and also ask the fsharp ppl if this is by design or not. |
Problem reproduction repo up: https://github.com/da9l/coverletWithAnonymousRecords |
The |
Thanks for the clarification @baronfel! I've updated the issue title to make it more clear to others what the problem is. |
Hello, I am experiencing the same problem and I have posted a simple example here in the hope that it will help: https://github.com/rhewitt316/coverlet-fsharp-anonymous-records-example I am using coverlet.console 3.0.3. Coverlet fails to instrument my example as-is. If the anonymous record is removed from my example, then instrumentation succeeds. |
Hi @rhewitt316 thank for the repro, we'll look into asap. |
There already is an issue at the fsharp repo for this dotnet/fsharp#11195. There also is a workaround described even if it isn't pretty. We could check the document table for entries that end with I'm personally don't really know if coverlet should handle such compiler bugs? @MarcoRossignoli @petli @petli I get your idea with 'just fail if all source files are missing'. The benefit would be to get rid of such issues like this one. The disadvantage would be a higher possibility for false positives if a library has just one same document name like the project. |
I think we should try to fix this issue F# is growing would be great provide coverage tool to this community. |
I've moved this part of the discussion to a new issue (#1164) to not distract from the F# situation here. |
Thanks @petli |
Thanks all for your effort in making this tool available and maintaining it. We have implemented the workaround pointed to by @daveMueller until a new version of coverlet console is released with the fix. |
FYI, I'm on version 3.1.0 and still seeing this issue. The workaround mentioned in dotnet/fsharp#11195 works, but it isn't exactly great. Is there something I can do to diagnose the issue further? |
@Arshia001 This should be fixed in Could you provide a repro of your issue? Then we could look into this again. By the way what coverlet driver are you using? E.g. the F# xunit template currently comes with |
@daveMueller No, I don't think I am. Here's the relevant section from my
I'll try to set up a minimal repro and get back to you. |
Yes thanks everything seems fine. Then most likely we missed something and a repro would really help. 👍 |
I deleted every old version of |
I have a F# solution with a web sdk api project, two shared libraries and some windows services.
Coverlet sucessfully instrument and analyze one of the shared libraries and the windows services but fails to instrument the api project and one of the libraries.
I've seen that there are similar issues here in the repo and while this could be a duplicate of one of those I have two detail that I think sets this apart.
I've tested with all three variants of coverlet 3.0.3: msbuild, collector and console and all three give the same result.
Inspecting the logs I see this for the failed instrumentations:
Unsuccessful library and unsuccessful api project,
Things I've tried and checked:
I have two questions:
[C:\myproject\src\api\unknown]
. The word "unknown" is not present in the coverlet repo so I assume it comes from something external to coverlet.The text was updated successfully, but these errors were encountered: