Add CSWINRT2021 analyzer for reads from write-only Span<T> parameters

[Sergio0694]

Summary

Adds a new Roslyn analyzer (CSWINRT2021, severity Warning) that detects when the implementation of an authored Windows Runtime method reads from a Span<T> parameter. Such parameters are projected as write-only fill arrays in the Windows Runtime ABI, so reading them is not supported.

Motivation

In the Windows Runtime ABI, array parameters use one of three conventions:

• ReadOnlySpan<T> -> pass array ([in], read-only)
• out T[] -> receive array ([out] with byref)
• Span<T> -> fill array ([out] without byref)

A fill array is write-only: the implementation is handed a caller-allocated buffer that it is expected to fill, and reading the existing contents is not supported (see this write-up on WinRT array parameters). Until now nothing flagged accidental reads from such a parameter, which can lead to subtle, hard-to-diagnose bugs in authored components. This analyzer surfaces the most common mistakes at compile time, while being careful to avoid false positives on legitimate write-only usage.

What it detects

For a by-value System.Span<T> parameter of a Windows Runtime-exposed method, the analyzer reports a read when it sees:

• Indexer reads: var x = span[i], Foo(span[i]), ref readonly var x = ref span[i], Foo(in span[i]), span[i]++, span[i] += 1

• Conversions of the span to ReadOnlySpan<T> (implicit or explicit), including when passed as an argument

• foreach iteration over the span, when the loop variable is by-value or ref readonly (every element is read)

• Reads through a writable ref foreach loop variable, which aliases the current element. The loop itself is valid (it can be used to fill the span), so only the individual reads are reported:

  public void Fill(Span<int> span)
  {
      foreach (ref int x in span)
      {
          int y = x;     // CSWINRT2021, this reads an uninitialized element
          x = 42;        // Fine, this writes to the element
      }
  }

Reading back what the method has written

Reading back a value the method itself has just written is perfectly valid, as the element being read is no longer uninitialized. The analyzer accounts for that, and skips a read whenever a write covering the same location is guaranteed to run before it:

public void Fill(Span<int> span)
{
    span.Clear();

    int a = span[0];                    // Fine, every element was initialized

    span[1] = 2;
    int b = span[1];                    // Fine, this element was initialized

    foreach (ref int x in span)
    {
        x = 3;
        int c = x;                      // Fine, this element was initialized
    }
}

The writes that are recognized are span.Clear() and span.Fill(value) (which cover any subsequent read, including foreach loops and ReadOnlySpan<T> conversions), and span[i] = value / Foo(out span[i]) (which cover subsequent reads of that same element, including in arguments and ref readonly aliases). The same two forms through a writable ref foreach loop variable cover subsequent reads of the element it aliases.

The analysis is deliberately conservative, since missing a write only means an extra warning, whereas trusting one that doesn't actually happen would silently hide a real bug. A write is only ever considered when it appears in a statement that precedes (an ancestor of) the read within a common enclosing block, and when it is unconditionally reached within that statement: anything nested in a construct that might be skipped is ignored (if, ?:, ??, ?., switch, loops, try, lambdas, local functions, && and ||, plus calls that the compiler can erase together with their arguments, such as [Conditional] methods, unimplemented partial void methods, and holes of an interpolated string whose handler can report failure). Only definite writes count, so ref arguments and writable ref aliases are not treated as initializing.

Nothing is skipped at all in a body that could modify a variable in a way the ordered scan of statements cannot see: one containing a goto, a lambda, a local function, a pointer, or a writable ref alias. On top of that, a write is discarded when the span parameter or the index variable might have been reassigned in between, when the index is itself a ref local or parameter (so it aliases storage that can change on its own), or when a reference to either of them is handed out anywhere in the method (as it can outlive the call that receives it).

Avoiding false positives

The analyzer only runs when authoring a component (CsWinRTComponent is true), and only for by-value Span<T> parameters of methods that are actually part of the ABI surface: public methods and constructors, or explicit implementations of public interfaces, declared on public, top-level classes. It intentionally does not warn on:

• Write-only usages of an element, whether accessed through the indexer or through a writable ref foreach loop variable: assignments (span[i] = value, x = value), out/ref arguments, and writable ref aliases (ref var slot = ref span[i])
• foreach loops with a writable ref loop variable, which can be used to fill all elements
• Non-indexer members such as span.Length and span.IsEmpty
• Parameters on private/internal methods, nested types, structs, or local functions, and ReadOnlySpan<T> parameters

Reads that flow through aliasing or a call to another method taking a Span<T> are an accepted blind spot, since the analyzer cannot reason about the callee's behavior.

Changes

• src/Authoring/WinRT.SourceGenerator2/Diagnostics/DiagnosticDescriptors.cs: add the CSWINRT2021 (WriteOnlySpanParameterRead) descriptor.
• src/Authoring/WinRT.SourceGenerator2/AnalyzerReleases.Shipped.md: register CSWINRT2021 under the 3.0.0 release.
• src/Authoring/WinRT.SourceGenerator2/Diagnostics/Analyzers/WriteOnlySpanParameterAnalyzer.cs: new analyzer, using an operation block action so that each candidate read can be inspected together with the code that necessarily runs before it.
• src/Tests/SourceGenerator2Test/Test_WriteOnlySpanParameterAnalyzer.cs: tests covering the warning cases, the write-only / non-exposed cases that must stay silent, and the reads that are skipped because the method has already written to the same location.