C# record constructors are not covered when SkipAutoProps is true

[jlawrence]

Describe the bug
C# record constructors are marked as uncovered whenever SkipAutoProps is true. But if SkipAutoProps is false, the coverage is correct.

To Reproduce

1. Create a file with a simple record
   public record MyRecord(int A);

2. Create a test that constructs the record
   var myRecord = new MyRecord(1);

Minimal Example: https://github.com/jlawrence/coverlet-missing-line-example/tree/main

Expected behavior
The record constructor should be covered regardless of the value of SkipAutoProps.

Actual behavior
Observed behavior: If SkipAutoProps is true, the record constructor will not be covered. If it is false, the record constructor will be covered.

Configuration:
* Coverlet package: "coverlet.collector" Version="6.0.0"
* .NET 8
* Windows 10 x64

[daveMueller]

Thanks for reporting. I didn't find time to look into this in detail but I guess the problem is the primary constructor. When there a new C# language features we often need to adapt to them. Especially if it's a feature where the compiler generates a lot of things like with primary constructors.
@Bertk @MarcoRossignoli I think we should look into primary constructors in general. Besides the primary constructors for records there is now also a variant of them for classes in C# 12.
Probably the easiest solution would be to skip them from coverage as they are just mere method signatures. On the other hand we could try to handle them like e.g. auto properties or so.
What do you think about it?
There is already another issue that also reports issues with primary constructors #1555.

[Bertk]

@daveMueller @MarcoRossignoli I am not sure whether it is possible to always ignore primary constructors. Maybe the skip auto property solution will be possible.

By the way, the current VS2022 preview (Version 17.9.0 Preview 1.1) also shows it as "Not Covered (Lines)"

There is a roslyn issue "Primary constructor properties have sequence points but breakpoints can't be placed" which has some additional information. Maybe we should implement this as default behavior.

5. test coverage should ignore sequence points in compiler generated code

[Bertk]

@jlawrence Could you please use the latest coverlet.collector preview from main branch and add ExcludeByAttribute option (see below).

This will ignore the primary constructor and generate a coverage.opencover.xml with visitedSequencePoints="0" for your repo.
Please send your feedback whether this is acceptable for your code coverage results.

nuget.config:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <!--To inherit the global NuGet package sources remove the <clear/> line below -->
    <clear />
    <add key="nuget" value="https://api.nuget.org/v3/index.json" />
    <add key="coverlet-nightly" value="https://pkgs.dev.azure.com/tonerdo/coverlet/_packaging/coverlet-nightly/nuget/v3/index.json" />
  </packageSources>
</configuration>

coverlet.runsetting:

<?xml version="1.0" encoding="utf-8"?>
<RunSettings>
  <DataCollectionRunSettings>
    <DataCollectors>
      <DataCollector friendlyName="XPlat code coverage">
        <Configuration>
          <SkipAutoProps>true</SkipAutoProps>
          <ExcludeByAttribute>Obsolete,GeneratedCodeAttribute,CompilerGeneratedAttribute</ExcludeByAttribute>
        </Configuration>
      </DataCollector>
    </DataCollectors>
  </DataCollectionRunSettings>
</RunSettings>

[daveMueller]

@daveMueller @MarcoRossignoli I am not sure whether it is possible to always ignore primary constructors. Maybe the skip auto property solution will be possible.

There is a roslyn issue "Primary constructor properties have sequence points but breakpoints can't be placed" which has some additional information. Maybe we should implement this as default behavior.

For records it's probably easy to skip the sequence points in the generated properties but for classes it generates instance fields. I admit I haven't looked into the IL for those two scenarios yet. But I'm interessted and could work on this as vacation time is approaching. Like @Bertk already started I would also look into how the other coverage tools are currently handling this.

[jlawrence]

@Bertk I tried out your solution, but excluding CompilerGeneratedAttribute has the undesired side effect of not covering async methods. Here are steps to reproduce:

1. Clone https://github.com/jlawrence/coverlet-missing-line-example/tree/coverlet-nightly
2. Check out the coverlet-nightly branch.
3. Follow instructions in readme file. You can see that async methods are no longer included in the coverage results.

[Bertk]

@jlawrence I see, So you have to wait until @daveMueller will provide a better solution.