Remove constraints on stackalloc (support new locations)

[gafter]

No description provided.

[gafter]

This change reflects the following behavior.

This is illegal:

    public void M() {
        var p = stackalloc nint[3];
    }

Because a stackalloc expression used as an initializer is of type T* (an unsafe pointer type) which requires an unsafe context. However, these are legal:

    public void M() {
        Span<nint> p = stackalloc nint[3];
    }

and

    public void M() {
        var p = (stackalloc nint[3]);
    }

(Note the addition of parens)

[gafter]

I don't understand the following behavior:

This is illegal:

    public void M() {
        var p = stackalloc nint[3][1];
    }

I don't understand why. Perhaps because `nint[3] is parsed as a type. I get the error

•	error CS0208: Cannot take the address of, get the size of, or declare a pointer to a managed type ('nint[]')
•	error CS1575: A stackalloc expression requires [] after type

Yet this is legal:

    public void M() {
        var p = (stackalloc nint[3])[1];
    }

[jskeet]

Is this intended to replace or be related to #604? I can't quite get my head round it all.

[BillWagner]

I think this looks good. We should discuss the general comments.

[BillWagner]

I don't understand the following behavior:

This is illegal:

    public void M() {
        var p = stackalloc nint[3][1];
    }

[...] Perhaps because `nint[3] is parsed as a type. I get the error

I think that's correct. It's trying to stackalloc an array of 1 where the element is nint[3], which is a managed type.

Yet this is legal:

    public void M() {
        var p = (stackalloc nint[3])[1];
    }

This surprises me as well. I think this should be illegal as well. According to sharplab, the type is ref IntPtr, which should be pointing to an array of elements. That would seem to mean the compiler took a reference to a managed type.

[KalleOlaviNiemitalo]

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

Because this stackalloc nint[3] expression is not the entire initialiser, its type is Span<nint> rather than nint*. Then, the [1] index means calling the get accessor of the public ref T this[int index] { get; } indexer of Span<T>. The result of this call has type ref nint. Next, the referenced nint value should be loaded from that location, but the compiler emits this load only in the Debug configuration and optimises it out in Release, because it has no side effects. The C# decompiler used by SharpLab shows a local variable ref IntPtr reference being initialised with the returned ref nint, but that variable is not the var p of the source code. In the Debug configuration, the decompiler instead shows IntPtr intPtr.

[Nigel-Ecma]

I don't understand the following behavior:

This is illegal:

    public void M() {
        var p = stackalloc nint[3][1];
    }

I don't understand why. Perhaps because `nint[3] is parsed as a type.

According to the v7 grammar it is not illegal and parses as an element_access of a stackalloc_expression. nint is an unmanaged_type, not a type, which excludes array types.

Note that the syntactically very similar new nint[3][1] is illegal as it was deemed confusing to allow it in the original C# design (and they syntactic method of making it illegal is the root of why the C# grammar isn’t “ANTLR ready” – but I digress ;-)). Maybe the compiler in question is approaching stackalloc as it does new and therefore declares it illegal?

The parenthesised version (stackalloc nint[3])[1] (and the similiar new) is also legal and parses exactly the same as the unparanethised version.