[ExcludeFromCodeCoverage] attribute not available on method generated from excluded method

[jakubch1]

Scenario is:
Method

        [ExcludeFromCodeCoverage]
        public async Task TestExcludedAsyncFunction()
        {
            await Task.Delay(1).ConfigureAwait(false);
        }

will generate class: .class nested private auto ansi sealed beforefieldinit '<TestExcludedAsyncFunction>d__2' which doesn't have any ExcludeFromCodeCoverage attribute so coverage tools will instrument and show coverage for it. We were trying to find ordinal number 2 on initial method but we fail using Microsoft.Reflection.Metadata, so we can't match those 2 methods.

Very similar issue we see for local methods, methods with yield, lambda. Could you please preserve ExcludeFromCodeCoverage attribute in such cases?

Related issue:
microsoft/vstest#2658

[tmat]

In general we don't want customers to depend on the compiler-generated metadata names. But there are scenarios, such as this one, stack trace prettification, etc. that need to reason about compiler-generated metadata entities in some way. We don't currently provide any tools that can be used in these scenarios which results in ad-hoc solutions that are brittle as they likely rely on compiler implementation details.

There are couple of approaches I can see we can take:

1. Most general approach with no changes to compiler

We create a new library (or source package) Microsoft.CodeAnalysis.Metadata.CSharp|VisualBasic that provides API abstraction for reasoning about compiler-generated metadata patterns. It would be in many aspects similar to already existing Microsoft.CodeAnalysis.Debugging source package. The library would not have dependency on compiler CodeAnalysis assemblies to avoid unnecessary bloat. Internally, we would share necessary compiler source files between this library and the compiler.

For this particular scenario the library could provide APIs such as string GetSourceMethodName(string), etc.

2. Specifically address only this issue by designating attributes that should be applied to all members emitted from a given member that an attribute is applied on.

For example, the compiler could recognize a new attribute ApplyToGeneratedMembersAttribute. If an attribute marked with this attribute is applied to a method all generated members from the method would also receive the attribute.

[tmat]

@jcouv @jaredpar

[jakubch1]

Dynamic code coverage needs only dll and pdb to work. We don't require source code. Please take it into account when designing this change.

[tmat]

@jakubch1 Yes, that's understood.

[jakubch1]

StateMachineKickoffMethod can be used to match async (yield) method with MoveNext. Anything similar for local/lambda?

[tmat]

No, we don't have that information in the PDB.

[jaredpar]

Moving to csharplang. How the attributes apply to generated code is generally driven by C# LDM (it's a gray area but considered part of the language design). Would need to get a language change here to change the compiler behavior.

@MadsTorgersen FYI