You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Provide compiler support for the new ExtendedLayoutAttribute approved in dotnet/runtime#100896 (to be implemented in .NET 10) by emitting [StructLayout(LayoutKind.Extended)] automatically in metadata and not showing [StructLayout(LayoutKind.Extended)] when decompiling metadata.
Background and Motivation
For .NET 10, the interop team has a new API to provide an extensible model for type layout of struct types. We will implement similarly to how we extended DllImportAttribute.CallingConvention, by using the last available bit in StructLayoutAttribute's LayoutKind to specify "look at this other attribute".
As part of this design, we noticed that the C# (and possibly VB) compilers validate the LayoutKind value that is passed into the StructLayoutAttribute to ensure it is one of the known values. As a result, we'd need to update Roslyn to allow this bit. To provide a cleaner experience, we'd like to do something slightly more involved. We'd like to enable the C# compiler to emit the correct metadata bit (1, which we'll define as LayoutKind.Extended) on the type when the new System.Runtime.InteropServices.ExtendedLayoutAttribute is applied.
Proposed Feature
When System.Runtime.InteropServices.ExtendedLayoutAttribute is applied to a type definition, the System.Runtime.InteropServices.StructLayoutAttribute pseudo-attribute is considered applied and the layoutKind is set to 1.
If a System.Runtime.InteropServices.StructLayoutAttribute is applied to a type with a layoutKind of 1 or LayoutKind.Extended explicitly, an error is issued.
If a type is imported with this layout kind from a NoPIA scenario, it the compiler will emit an error and not embed the type.
Alternative Designs
Alternatively, we only enable Roslyn to allow the LayoutKind.Extended value to be passed to System.Runtime.InteropServices.StructLayoutAttribute. In this alternative, any time the new attribute is used, StructLayoutAttribute would also have to be applied for it to have any effect. This would provide a worse UX but be cheaper to implement.
The text was updated successfully, but these errors were encountered:
Summary
Provide compiler support for the new
ExtendedLayoutAttribute
approved in dotnet/runtime#100896 (to be implemented in .NET 10) by emitting[StructLayout(LayoutKind.Extended)]
automatically in metadata and not showing[StructLayout(LayoutKind.Extended)]
when decompiling metadata.Background and Motivation
For .NET 10, the interop team has a new API to provide an extensible model for type layout of struct types. We will implement similarly to how we extended
DllImportAttribute.CallingConvention
, by using the last available bit inStructLayoutAttribute
'sLayoutKind
to specify "look at this other attribute".As part of this design, we noticed that the C# (and possibly VB) compilers validate the
LayoutKind
value that is passed into theStructLayoutAttribute
to ensure it is one of the known values. As a result, we'd need to update Roslyn to allow this bit. To provide a cleaner experience, we'd like to do something slightly more involved. We'd like to enable the C# compiler to emit the correct metadata bit (1
, which we'll define asLayoutKind.Extended
) on the type when the new System.Runtime.InteropServices.ExtendedLayoutAttribute is applied.Proposed Feature
When
System.Runtime.InteropServices.ExtendedLayoutAttribute
is applied to a type definition, theSystem.Runtime.InteropServices.StructLayoutAttribute
pseudo-attribute is considered applied and thelayoutKind
is set to1
.If a
System.Runtime.InteropServices.StructLayoutAttribute
is applied to a type with alayoutKind
of1
orLayoutKind.Extended
explicitly, an error is issued.If a type is imported with this layout kind from a NoPIA scenario, it the compiler will emit an error and not embed the type.
Alternative Designs
Alternatively, we only enable Roslyn to allow the
LayoutKind.Extended
value to be passed toSystem.Runtime.InteropServices.StructLayoutAttribute
. In this alternative, any time the new attribute is used,StructLayoutAttribute
would also have to be applied for it to have any effect. This would provide a worse UX but be cheaper to implement.The text was updated successfully, but these errors were encountered: