Better support for unmanaged-like types

[vmilea]

Background

Recent efforts have improved the predictability of layout in managed memory (for example, non-blittable bool / char fields no longer break sequential layout on the managed side). This enables high-performance serialization and interop without runtime marshalling or explicit layout attributes.

Motivation

I'm building an API that that takes blittable types:

void Blit(ReadOnlySpan<T> items) { ... }

"Blittable" in this case means unmanaged or nullable unmanaged. Yes, Nullable<T> where T : unmanaged is in fact blittable, let's move on. :)

Because Nullable<T> doesn't satisfy the struct / unmanaged constraints, you end up defining multiple overloads:

void Blit<T>(in T value) where T : unmanaged { ... }
void Blit<T>(in T? value) where T : unmanaged { ... }

This becomes exponentially worse the more blittable parameters there are:

void Blit<T1, T2>(in T1 a, in T2 b) where T1 : unmanaged where T2 : unmanaged { ... }
void Blit<T1, T2>(in T1 a, in T2? b) where T1 : unmanaged where T2 : unmanaged { ... }
void Blit<T1, T2>(in T1? a, in T2 b) where T1 : unmanaged where T2 : unmanaged { ... }
void Blit<T1, T2>(in T1? a, in T2? b) where T1 : unmanaged where T2 : unmanaged { ... }

So I decided to leave T unconstrained and instead throw an exception when the RuntimeHelpers.IsReferenceOrContainsReferences<T>() intrinsic returns false. This approach detects issues at runtime with zero overhead, but I'd like to add an analyzer error in case of misuse.

void Blit<[Blittable] T>(in T value) { ... }
...

Blit("oops"); // Error: Type 'string' is not Blittable

Proposed API

A couple of additions to the Roslyn API would help:

• ITypeSymbol.IsReferenceOrContainsReferences: Equivalent to RuntimeHelpers.IsReferenceOrContainsReferences. Can already be done by checking all fields in a struct recursively, but should be faster through a dedicated API.

• INamedTypeSymbol.LayoutKind: So the analyzer can warn against auto layout, which is currently tricky to infer (e.g. can't assume sequential layout for a struct lacking StructLayoutAttribute because it might be a forwarded type like ValueTuple and it has a TypeForwardedFromAttribute instead of the original attributes).

Risks

Can't see any.

[vmilea]

I've realized that IsReferenceOrContainsReference is unnecessary. Instead, you can check if the type is unmanaged or a nullable type with an unmanaged underlying type -- no recursion required.

[333fred]

I don't know how we'd implement LayoutKind in the compiler. Just like you, we cannot presume what the kind of the type symbol we see is; it could further change at runtime, so anything we reported would be a best guess anyway. I'll let @AlekseyTs chime in as well as the API owner, but I do not think this is an API that we can support.

[AlekseyTs]

Compiler doesn't define or enforce type layout. Anyone can implement what they think runtime is going to do in terms of layout for a particular type (I think some of the aspects aren't documented and some are runtime version dependent). From the language point of view and for the purpose of compiling a program, compiler doesn't need to figure this out. Therefore, I do not think it is appropriate to provide an API like that directly on a type symbol.

[333fred]

Thanks Aleksey. I'm going to close this out as not planned.

[vmilea]

Compiler doesn't define or enforce type layout. Anyone can implement what they think runtime is going to do in terms of layout for a particular type (I think some of the aspects aren't documented and some are runtime version dependent). From the language point of view and for the purpose of compiling a program, compiler doesn't need to figure this out.

I'm asking for Roslyn to expose the layout kind from IL metadata, as specified in ECMA-335 I.9.5.

How the runtime determines the final layout is a separate matter. From the point of view of a library writer: unmanaged types have predictable layout since .NET 7, which I rely for critical optimizations in serialization / interop. The only pitfall is autolayout.

[AlekseyTs]

I'm asking for Roslyn to expose the layout kind from IL metadata, as specified in ECMA-335 I.9.5.

Thank you for the clarification. I guess we have at least two options:

1. Return just LayoutKind, i.e. the value available from NamedTypeSymbol.Layout.Kind internal API
2. Or, return value of internal type TypeLayout from NamedTypeSymbol.Layout internal API

@vmilea Please confirm that either option is going to address your scenario.

[vmilea]

@vmilea Please confirm that either option is going to address your scenario.

Thanks, the first option is sufficient.

TypeLayout itself could be confusing. For example, what is the size of struct X { bool B; }? Is it 1 - the managed size? Or 4 - the marshalled size? No, it's actually 0 because no .size directive was given.

[333fred]

@vmilea can you please update your post by spelling out the exact API shape you're proposing?