`ref struct`s get code cleaned to `internal struct`, dropping the ref

[lcsondes]

Environment

• Visual Studio version: 2019 Community
• CodeMaid version: 11.1
• Code language: C#

Description

using System;

ref struct Bug // This will get code cleaned to internal struct, which won't compile
{
    private Span<int> x;
}

internal class Program
{
    public static void Main()
    {
    }
}

Steps to recreate

Code cleanup the above code snippet.

Current behavior

ref struct is changed to internal struct. This is a breaking change even if it didn't contain a Span<T>.

In the case of ref readonly struct it gets cleaned to ref readonly internal struct which does not compile either.

Expected behavior

Not breaking the code.

[codecadwallader]

Thanks for reporting the issue. I am unable to reproduce it placing that code inside an existing C# console application. Can you please provide a minimal solution that reproduces the issue for you, as well as your CodeMaid settings in case there is a combination that may be causing the issue?

[lcsondes]

It's a fresh project. This is the csproj, have it next to the sample file above:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp3.1</TargetFramework>
  </PropertyGroup>

</Project>

[codecadwallader]

I do have a .csproj that matches that configuration, but I'm still unable to reproduce it. To make sure there isn't some unexpected difference between our environments, can you please attach your minimal solution?

[lcsondes]

Here: CsSandbox.zip

Clean up Program.cs and ref struct Test will become internal struct Test.

[codecadwallader]

Thanks for providing that example, I am able to reproduce it now. Interestingly enough, the difference of having the trailing comment // This will get code cleaned.. is what makes the bug occur or not occur.

The insert explicit access modifier logic uses the VS API to add the "current" access modifier if it's not found within the declaration. We previously found this would cause a similar issue with explicit interface implementations and had to make an exception case for it. I suspect we may need to do the same thing here and extend the unit tests to cover this scenario.