Support new stackalloc expression locations

[RexJaeschke]

No description provided.

[BillWagner]

This LGTM @RexJaeschke

@jskeet Let's put this on the agenda for the next meeting to approve.

[KalleOlaviNiemitalo]

That implicit conversion seems wrong to me. How would it decide the number of elements in the System.Span<T>?

using System;

public class C {
    public unsafe void M() {
        int* pointer = stackalloc int[3];
        
        Span<int> span;
 
        // error CS0029: Cannot implicitly convert type 'int*' to 'System.Span<int>'
        span = pointer;
    }
}

Instead, you should have an implicit conversion only from a stackalloc_expression to a span type.

[KalleOlaviNiemitalo]

Likewise error CS0029 here:

Span<int> span = (int*)null;

var deduces a pointer type, though:

public class C {
    public unsafe void M() {
        var a = stackalloc int[3];
        MustBePointer(ref a); // OK
    }
    
    static unsafe void MustBePointer(ref int* p) {}
}

But not when parenthesized:

public class C {
    public unsafe void M() {
        var a = (stackalloc int[3]);
        MustBePointer(ref a); // error CS1503: Argument 1: cannot convert from 'ref System.Span<int>' to 'ref int*'
    }
    
    static unsafe void MustBePointer(ref int* p) {}
}

[jskeet]

This objection looks reasonable - and if we can just change it to an implicit conversion from stackalloc_expression, I think that should be simple. But I don't know the origin of this change, so that could be missing something.

[Nigel-Ecma]

Agree with @KalleOlaviNiemitalo, the conversion from a pointer must be wrong.

An implicit conversion from a stackalloc_expression to Span<T> is not required as that is the type of such an expression in safe code, from §12.8.21:

The result of a stackalloc_expression is an instance of type Span<T>, where T is the unmanaged_type…

In unsafe code it can be a pointer or a Span<T>, from §23.9:

In an unsafe context if a stackalloc_expression (§12.8.21) occurs as the initializing expression of a local_variable_declaration (§13.6.2), where the local_variable_type is either a pointer type (§23.3) or inferred (var), then the result of the stackalloc_expression is a pointer of type T * to be beginning of the allocated block, where T is the unmanaged_type of the stackalloc_expression.

In all other respects the semantics of local_variable_declarations (§13.6.2) and stackalloc_expressions (§12.8.21) in unsafe contexts follow those defined for safe contexts.

The added conversion wouldn’t make sense even in unsafe code, unless the resulting span had infinite length (and couldn’t be passed to safe code!)

Just delete this added conversion.

[jskeet]

From discussion, we should reimplement this PR to look more like https://github.com/dotnet/csharplang/blob/main/proposals/csharp-8.0/nested-stackalloc.md - that doesn't talk about a conversion from pointer types, and explains the oddity of the change of type when the expression is parenthesized.

[jskeet]

Neal is going to make the change - either in this PR or in one which supercedes it.

[Nigel-Ecma]

Removal of the 7.3 restrictions look fine.

The addition of the implicit conversion from a pointer to a Span needs to go.

[Nigel-Ecma]

Agree with @KalleOlaviNiemitalo, the conversion from a pointer must be wrong.

An implicit conversion from a stackalloc_expression to Span<T> is not required as that is the type of such an expression in safe code, from §12.8.21:

The result of a stackalloc_expression is an instance of type Span<T>, where T is the unmanaged_type…

In unsafe code it can be a pointer or a Span<T>, from §23.9:

In an unsafe context if a stackalloc_expression (§12.8.21) occurs as the initializing expression of a local_variable_declaration (§13.6.2), where the local_variable_type is either a pointer type (§23.3) or inferred (var), then the result of the stackalloc_expression is a pointer of type T * to be beginning of the allocated block, where T is the unmanaged_type of the stackalloc_expression.

In all other respects the semantics of local_variable_declarations (§13.6.2) and stackalloc_expressions (§12.8.21) in unsafe contexts follow those defined for safe contexts.

The added conversion wouldn’t make sense even in unsafe code, unless the resulting span had infinite length (and couldn’t be passed to safe code!)

Just delete this added conversion.

[gafter]

The precedence rules (grammar) for stackalloc_expression is no longer correct for C# 8. It is shown in the grammar as a primary_no_array_creation_expression, but we can see from the behavior of the compiler (and by the intent of the purpose of that grammar rule) that is should instead be primary_expression. Specifically, this is not allowed:

        var o = stackalloc nint[3][1];

but this is allowed

        var o = (stackalloc nint[3])[1];

I think it must be this way because stackalloc expressions may contain an initializer.

[gafter]

I'm working on a replacement PR for this.

[gafter]

This PR has been revised and incorporated into #1211