Suppress emitting of localsinit flag. (VS 16.8, .NET 5)

[tannergooding]

• Proposed
• Prototype: https://github.com/dotnet/roslyn/tree/features/localsinit
• Implementation: Not Started
• Specification: Not Started

Adding SkipLocalsInitiAttribute to CoreCLR: dotnet/coreclr#20093

[tannergooding]

CC. @jaredpar. I logged this issue to track: https://github.com/dotnet/csharplang/blob/master/proposals/skip-localsinit.md

I believe we need a new proposal champion to finish pushing this through the compiler.

[MrJul]

Will the SkipLocalsInitAttribute be restricted to unsafe methods only? (either with a warning or the attribute simply being ignored on safe methods).

While reading the proposal, I assumed that there'll be some kind of restriction (because of potentially unverifiable code), but that's not stated explicitly.

[tannergooding]

This is linked to the CoreFX API: https://github.com/dotnet/corefx/issues/29026

[tannergooding]

@MrJul, not as proposed.

If the user adds the attribute to a method, they are opting into the behavior and into any "unverifiable" functionality.

NOTE: For most "safe" code, dropping localsinit is "safe" and can be made verifiable by updating the tooling to check that the local is written before first use. One exception would be for Span<T> x = stackalloc T[];, which is allowed in safe code but would not be verifiable.

[tannergooding]

This already has a prototype/implementation: https://github.com/dotnet/roslyn/tree/features/localsinit

The remaining work is just the general cleanup required to merge this back into master.

We should look at getting this done for 8.0, if possible. CC: @agocke, @jaredpar, @jcouv

[jkotas]

NOTE: For "safe" code, dropping localsinit is "safe" and can be made verifiable by updating the tooling to check that the local is written before first use.

Nit: This is not true for Span stackalloc.

[tannergooding]

Ah right, Span<T> x = stackalloc T[] is allowed in safe code now. I've updated the comment about to indicate "most safe code" and to give the above as an example of where it is not.

[pentp]

To keep safe code safe, it would help if the compiler disallowed Span stackalloc in methods under the scope of this attribute, unless the method is marked unsafe. This wouldn't break any existing code and should be a pretty simple check on the stackalloc expression.

[agocke]

@jkotas and I talked about this at length. The two reasons why I decided against that:

1. The level of unsafety is not that high. Since you can only stackalloc unmanaged types and Span still provides bounds checking, you can't really break the type system, you can only end up with garbage data.

2. There are actually a bunch of ways, even in pure safe code, to end up with garbage data. The most common one is using various interop/marshalling APIs, but recently CoreFX added ArrayPool, which doesn't clear the arrays when freeing. The same thing can happen through various Memory<T> manipulations.

Both of these things together made me think that this wasn't necessarily worth marking every method with stackalloc unsafe, but it was worth at least a small warning, which is why I changed the SkipLocalsInit attribute to require that /unsafe is passed to the compiler. This felt like a good middle ground, to me.