-
Notifications
You must be signed in to change notification settings - Fork 4.2k
Implement compiler support for System.Runtime.InteropServices.ExtendedLayoutAttribute #78741
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
…tribute Some error handling is still missing. NoPia tests are still TBD
|
@jkoritzinsky think we'll need a small specification document for this contribution. |
|
I'll put one together. Where is the best place for it to go? |
dotnet/csharplang. @333fred can you think of a good example that would be similar to this? |
|
I considered doing a proposal in csharplang, but there's zero specifications of |
|
I would agree with Jeremy, C# the language doesn't care about those attributes, just Roslyn the compiler. Perhaps under docs/features? Also, what support does VB have for these attributes, and what will we need to update in its support? |
|
Hmm ... for some reason I thought the spec discussed |
|
I'll drop a spec in docs/features and add VB support. |
…ther layout or layout-like attributes.
|
I've added a spec and added VB support |
…Kind to be defined in InternalSpecialType to enforce the "defined in CoreLib" requirement.
…nch 'main' of github.com:dotnet/roslyn into extended-layout
|
This is generally looking ok to me. @dotnet/roslyn-compiler for a second review. |
| // System_Runtime_CompilerServices_AsyncStateMachineAttribute__ctor | ||
| (byte)MemberFlags.Constructor, // Flags | ||
| (byte)WellKnownType.System_Runtime_CompilerServices_AsyncStateMachineAttribute, // DeclaringTypeId | ||
| (byte)WellKnownType.ExtSentinel, (byte)(WellKnownType.System_Runtime_CompilerServices_AsyncStateMachineAttribute - WellKnownType.ExtSentinel), // DeclaringTypeId// DeclaringTypeId |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| (byte)SignatureTypeCode.TypeHandle, (byte)InternalSpecialType.System_Threading_Tasks_Task_T, | ||
| 1, | ||
| (byte)SignatureTypeCode.TypeHandle, (byte)SpecialType.System_Int32, | ||
| // System_Runtime_InteropServices_ExtendedLayoutAttribute__ctor |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: consider also adding a line break above #Closed
| } | ||
|
|
||
| if (containingType.HasStructLayoutAttribute || containingType.HasInlineArrayAttribute(out _)) | ||
| if (containingType.HasStructLayoutAttribute || containingType.HasExtendedLayoutAttribute || containingType.HasInlineArrayAttribute(out _)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's another usage of HasStructLayoutAttribute below at line 2768. Should it also be updated? #Closed
| return default(TypeLayout); | ||
|
|
||
| default: | ||
| if ((def.Attributes & TypeAttributes.LayoutMask) == TypeAttributes.ExtendedLayout) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ExtendedLayout is emitted as an attribute, unlike StructLayout, We should decide what to do when the extended flag and the [ExtendedLayout(...)] attribute don't agree, in metadata.
I couldn't find any place where the compiler cares about the value from Layout from metadata, outside of verifying that the information round-trips through metadata. Is there any other scenario where it matters?
In any case, let's add a test (you can use CreateCompilationWithIL).
Btw, do we have a test observing that ExtendedLayout attribute is emitted? #Closed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's no other case that Roslyn cares about the Layout metadata. I'll add some IL tests to validate behavior when the attribute and the metadata bits disagree.
| CreateEmptyCompilation( | ||
| source, | ||
| references: [s_extendedLayoutAttributeMinimalCoreLibrary]) | ||
| .VerifyDiagnostics( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's use VerifyEmitDiagnostics for all tests that error. It pulls a bit further in the compilation pipeline and we sometimes find issues with later pipeline phases that have trouble dealing with unexpected configuration of symbols. #Closed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is no VerifyEmitDiagnostics when using CompileAndVerify. It looks like VerifyDiagnostics on the CompilationVerifier looks at the emit diagnostics though. Is that okay?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right. If you just create a compilation and verify diagnostics, then use VerifyEmitDiagnostics. If you use CompileAndVerify (which already emits) then use VerifyDiagnostics on that.
| CreateEmptyCompilation( | ||
| source, | ||
| references: [s_extendedLayoutAttributeMinimalCoreLibrary]) | ||
| .VerifyDiagnostics( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's also verify what the symbols report in this error scenario #Closed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried moving this to use CompileAndVerify, but because it has error diagnostics, it fails to emit. I'm going to write this as Assert calls on top of the returned compilation, ok? Or is there another way I should do this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, you can get symbols from the compilation. var comp = CreateCompiation(...); var e = comp.GlobalNamespace.GetTypeMember("E"); ... assert on e ...
|
|
||
| If HasExtendedLayoutAttribute And Not ContainingAssembly.RuntimeSupportsExtendedLayout Then | ||
| diagnostics = BindingDiagnosticBag.GetInstance() | ||
| diagnostics.Add(ERRID.ERR_RuntimeDoesNotSupportExtendedLayoutTypes, GetFirstLocation(), Me) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have a test for this in VB? Found it: ExtendedLayoutAttribute_DefinedInOtherAssembly_Errors #Closed
| If diagnostics Is Nothing Then | ||
| diagnostics = BindingDiagnosticBag.GetInstance() | ||
| End If | ||
| diagnostics.Add(ERRID.ERR_StructLayoutAndExtendedLayout, GetFirstLocation()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have a test for this in VB? Found it: ExtendedLayout_OtherLayoutKind_Errors #Closed
| If Me.IsGenericType Then | ||
| diagnostics.Add(ERRID.ERR_StructLayoutAttributeNotAllowed, arguments.AttributeSyntaxOpt.GetLocation(), Me) | ||
| End If | ||
| ElseIf attrData.IsTargetAttribute(AttributeDescription.ExtendedLayoutAttribute) Then |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
StructLayout appears disallowed on generic types (a few lines above). Should the same restriction apply to ExtendedLayout? #Closed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a VB-only restriction, C# does not block it. Additionally, I think that that restriction is both not necessary for ExtendedLayout and would block key scenarios if we did it across the board. If we wanted to block it just for VB though, I personally don't really care one way or the other. I don't expect anyone to use this from VB.
| Structure C | ||
| ~ | ||
| ]]>) | ||
| End Sub |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have a test for partial types in VB? #Closed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's no warning from the VB compiler when partial members are split across types for types that are explicitly LayoutKind.Sequential, so I didn't add the same feature for extended layout (and as a result did not add a test for partials). I can add one if you'd like just to validate the metadata.
| To provide the user experience requested by the runtime team, the C# and VB compilers will have the following support for this attribute: | ||
|
|
||
| - If a type has the `ExtendedLayoutAttribute` applied, the compiler will emit the `TypeAttributes.ExtendedLayout` value in the type's `TypeAttributes` flags. | ||
| - If a type has the `ExtendedLayoutAttribute` applied, the compiler will not allow the `StructLayoutAttribute` to be applied to the type. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not related to this PR: The linked API proposal wasn't updated to clarify that ExtendedLayout attribute implies StructLayout(Extended). The code samples still show explicit [StructLayout(Extended)].
| @@ -0,0 +1,16 @@ | |||
| System.Runtime.InteropServices.ExtendedLayoutAttribute Compiler Support | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not related to this PR: will the F# compiler need to be updated as well? Consider filing an issue #Closed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
F# issue opened as well: dotnet/fsharp#19190
F# shouldn't need any changes to consume, but it will need changes to correctly produce types with the right bits set.
jcouv
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done with review pass (commit 28)
src/Compilers/CSharp/Test/Emit3/Attributes/AttributeTests_StructLayout.cs
Outdated
Show resolved
Hide resolved
jcouv
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM Thanks (commit 30) modulo unnecessary using
The interop team has decided to add a new mechanism to specify type layouts, designed similarly to how the
UnmanagedCallersOnlyfeature was designed. In particular, the team has decided to use the last remaining value in the "Layout Kind" mask of a type def's attributes to represent "extended layout". When this value it set, the runtime will look for theSystem.Runtime.InteropServices.ExtendedLayoutAttributeto provide all layout information.As part of the design process, we noticed that Roslyn blocks emitting a type with the last remaining value of the
System.Runtime.InteropServices.LayoutKindenumeration in theStructLayoutpseudo-attribute as the compiler can't map it to a validTypeAttributesvalue.The
System.Runtime.InteropServices.ExtendedLayoutAttributetype was approved in dotnet/runtime#100896 and has the first part of runtime implementation (the TypeAttributes bit and the LayoutKind value) in dotnet/runtime#116082.The support in C# is to allow the user to specify the
ExtendedLayoutAttributeon a type. When they do so, the correct layout bit will be set. The user cannot manually specify the new "extended layout" value. The only way in C# to specify that value is to put this attribute on the type.The
ExtendedLayoutAttributewill be embedded in NoPia scenarios as the layout bits are embedded in NoPia scenarios.This should go into .NET 11