Decorate generated code from inline functions with an 'FSharpInlineFunction' attribute

[rca22]

When an inline function is written in F# and compiled, most uses of this function are conceptually replaced by the body of the function during compilation, however in the generated assembly, a non-inline version of this function remains, so that it can be accessed via reflection and used as a function parameter, etc. (I assume).
I would like this code to be decorated with a new attribute, FSharpInlineFunction or similar. The primary purpose of this would be to allow me to remove the uses of this function from reports produced by code coverage tools such as dotcover. There is no way that I know of that it is logically possible for a code coverage tool to detect all calls correctly to an inline function all the time, as by definition, if inlined, no information remains after compilation at the point this code was called. Hence, in my experience, tools return that inline functions are untested, whether they are or are not...

As a comparison, I already have to do something similar to remove 'untested functions' listed in reports by such tools for the properties generated when an F# record is compiled, the standard implementation of Object.ToString() for F# types such as records and DUs, etc. These are nicely decorated by CompilerGenerated attribute and so are easy to remove; an F# programmer should be able to assume such code is correct by definition, so it doesn't add anything useful to the information in the report.

[abelbraaksma]

I agree it would be nice to have some kind of attribute. Such generated methods for inline functions have a body that just throws an exception (with a message often using the wrong function name, mind you, but I guess that's a bug).

Of course, you could use something like Fody to do this, as the body is such functions of always the same, meaning you can find them and weave them. But that's just a workaround.

as by definition, if inlined, no information remains after compilation at the point this code was called

There's a language suggestion somewhere out there that would fix this, sucg that the PDB would get the right file, line and row information for code coverage tools. @dsyme mentioned it isn't that hard to fix, but it isn't trivial either. If that makes it into vNext, an attribute wouldn't be needed anymore.

[rca22]

If the PDB were fixable, then that would sort out the issue with code coverage better than filtering based on an attribute, as you'd be able to get an accurate report for inline functions, rather than excluding them. If that were developed I'd be perfectly satisfied. Regardless though, it's difficult to see the downside of additional metadata which will, no doubt, turn out to have other uses, just not the particular one I've suggested.

[rca22]

@abelbraaksma @dsyme any update on whether the potential improvement to the PDB to get the file & line information for inline functions has any takers. This issue is really making any code coverage analysis of our unit tests for function modules containing inline functions completely meaningless...

[abelbraaksma]

@rca22 there's a new feature that allows you to create debug points in inlined functions. I wonder if that also works with code coverage tools. It was added to make debugging of resumable code easier.

There's also a line and file compiler directive that you could use, but that's rather clumsy. The compiler should be able to help here, of course.

[rca22]

Thanks for the update. @abelbraaksma. Can you provide a link to the new feature, please? I can't seem to find it by Googling.