Broken `VariableLengthInlineArray<T>` after upgrade from 0.3.49-beta to 0.3.106

[oold]

Actual behavior

Multiple build errors for VariableLengthInlineArray<T>:

Windows.Win32.VariableLengthInlineArray.g.cs(30,27,30,34): error CS8170: Struct members cannot return 'this' or other instance members by reference
Windows.Win32.VariableLengthInlineArray.g.cs(30,12,30,42): error CS8347: Cannot use a result of 'Unsafe.Add<T>(ref T, int)' in this context because it may expose variables referenced by parameter 'source' outside of their declaration scope

Expected behavior

The build succeeds.

Repro steps

1. NativeMethods.txt content:

   
   ApplicationDocumentLists
   CopyFileEx
   CoTaskMemFree
   ExtractIconEx
   FileOpenDialog
   FileSaveDialog
   GetActiveWindow
   GetModuleFileName
   GetSystemWindowsDirectory
   HRESULT_FROM_WIN32
   IApplicationDocumentLists
   IEnumObjects
   IFileDialog
   IShellItem2
   ITaskbarList3
   SendMessage
   SetActiveWindow
   SHAddToRecentDocs
   SHCreateItemFromParsingName
   SHGetKnownFolderItem
   SHOpenFolderAndSelectItems
   SHParseDisplayName
   SHSetTemporaryPropertyForItem
   StrCmpLogical
   TaskbarList
   TaskDialogIndirect

E* FOLDERID ICON_ MAX_PATH MESSAGEBOXRESULT PBST PKEY_ S_ SHARD TASKDIALOG_ELEMENTS TASKDIALOGMESSAGES TD WIN32ERROR WM*

2. `NativeMethods.json` content (if present):
```json

3. Any of your own code that should be shared?

Context

• CsWin32 version: 0.3.106
• Win32Metadata version (if explicitly set by project): 60.0.34-preview
• Target Framework: net5.0-windows

[AArnott]

I can't repro the problem. Can you provide a minimal repro project?

I couldn't repro even when targeting net5.0-windows as you mentioned. But FYI, we probably won't fix any bugs that are unique to that target framework, since the runtime itself is no longer supported by Microsoft.

[oold]

cswin32-issue1205-repro.zip The issue only occurs when building with Visual Studio 2019. I wasn't able to reproduce it in VS Code.

[AArnott]

Oh! In that case I suspect the issue is the .NET SDK version you're compiling with. Can you type dotnet --list-sdks or otherwise tell me which SDK version you're using? VS2019 is a clue, but it isn't definitive.

[oold]

> dotnet --list-sdks
3.1.426 [C:\Program Files\dotnet\sdk]
5.0.203 [C:\Program Files\dotnet\sdk]
5.0.214 [C:\Program Files\dotnet\sdk]
5.0.406 [C:\Program Files\dotnet\sdk]
5.0.408 [C:\Program Files\dotnet\sdk]
5.0.416 [C:\Program Files\dotnet\sdk]
6.0.203 [C:\Program Files\dotnet\sdk]
6.0.300 [C:\Program Files\dotnet\sdk]
6.0.407 [C:\Program Files\dotnet\sdk]
8.0.201 [C:\Program Files\dotnet\sdk]

MSBuild is using SDK version 6.0.203.

[AArnott]

Great. I got it by using the 6.0.423 SDK and C# lang version 9. Investigating further...

[AArnott]

The C# language version isn't what does it. It's just the compiler version. The compiler that ships in .NET SDK 6.0.x fails where .NET SDK 8's compiler works. I guess the older compiler didn't know how to respect the [UnscopedRef] attribute. I suspect the only workaround we can make in the source generator will be to avoid emitting the VariableLengthInlineArray<T> type for that version of the compiler. That's trouble though, because the source generator isn't told what the compiler version is, I think. I'll have to get the roslyn team's take on it.

[jaredpar]

The Unsafe.Add is a bit of a red herring here, from a ref safety standpoint the method looks like this:

internal ref T this[int index]
{
    [UnscopedRef]
    get => ref this.e0;
}

I guess the older compiler didn't know how to respect the [UnscopedRef] attribute

That is correct. The attribute was added in .NET 7 so the .NET 6 compiler doesn't attach any special meaning to it. From the perspective of .NET 6 compiler this method has no attribute and is a ref safety violation.

That's trouble though, because the source generator isn't told what the compiler version is, I think. I'll have to get the roslyn team's take on it.

Think it would be better to look at the language version than compiler version. That is available through parse options on the source files. In this case the language version is 9.0 which doesn't support ref fields, [UnscopedRef], etc ... That should be enough to know when this pattern is / isn't safe to code gen.

Note: in November the .NET 6 SDK goes out of support and at that time all supported compilers will be able to use these attributes. This pattern might be tricky to emit in older compilers.

[Nuklon]

With .NET Framework this also causes problems. If you don't include the latest System.Runtime.CompilerServices.Unsafe package it fails to build with:

Error (active) CS0117 'Unsafe' does not contain a definition for 'SkipInit'