Allow taking unmanaged/pinned addresses of readonly lvalues.

[VSadov]

Allow taking unmanaged/pinned addresses of readonly variables.

Fixes:#22306

Customer scenario

Historically we require that lvalue is writable before allowing taking a pointer.
While there are ways to "cast away" readonliness, why is that even required before "casting away" most of the type system safeguards anyways?

After introducing more readonly variables in the language, the limitation becomes more apparent. - In anticipation of unsafe use, API creators avoid readonly even for safe scenarios. - Not a desirable outcome.

See for example
https://github.com/dotnet/corefx/blob/fa27201badbbce3cdb752d52593493a60c2f7d34/src/System.Memory/src/System/ReadOnlySpan.cs#L309

public ref T DangerousGetPinnableReference() on ReadOnlySpan<T> returns an ordinary reference to the first element (on an otherwise readonly data type).
It could instead return a readonly ref, but that would inconvenience the users since the main purpose is to use this method in “fixed” statement.

[tannergooding]

@VSadov, does this also allow:

public class MyClass
{
    private static readonly Guid MyGuid = new Guid("");

    public void MyMethod()
    {
        fixed (Guid* pMyGuid = &MyGuid)
        {
        }
    }
}

[VSadov]

@tannergooding - yes. That is the point.

You do not need to jump through hoops like:

public class MyClass
{
    private static readonly Guid MyGuid = new Guid("");

    public void MyMethod()
    {
        fixed (Guid* pMyGuid = &System.Runtime.CompilerServices.Unsafe.AsRef(in MyGuid))
        {
        }
    }
}

[tannergooding]

Awesome! (I assumed it would, I just wanted to make sure since the title indicated variables, which I assumed to mean locals, rather than also including fields).

[VSadov]

"readonly variables" - to mean generally an lvalue that is readonly.
That includes fields, locals, ref readonly methods/indexers, etc...

[VSadov]

@dotnet/roslyn-compiler - please review

[jcouv]

        int **j = &i;  // CS0459

The error code comments can be removed. #Pending

---

Refers to: src/Compilers/CSharp/Test/Semantic/Semantics/SemanticErrorTests.cs:10270 in 7cfa15e. [](commit_id = 7cfa15e04778b2abc200a5383891b110e528d06a, deletion_comment = False)

[VSadov]

CC: @jkotas - FYI

[VSadov]

        int **j = &i;  // CS0459

Perhaps the error itself can be removed too.

---

In reply to: 332912171 [](ancestors = 332912171)

---

Refers to: src/Compilers/CSharp/Test/Semantic/Semantics/SemanticErrorTests.cs:10270 in 7cfa15e. [](commit_id = 7cfa15e04778b2abc200a5383891b110e528d06a, deletion_comment = False)

[jcouv]

LGTM and approved for 15.5 pending another review.

[agocke]

LGTM

[agocke]

Is this something we're just keeping around until the verifier is updated?

[VSadov]

Yes. A last-resort workaround if compatibility with PEVerify is needed. - It does not always work with new features,as some features by definition do not conform with PEVerify, but at least for old features it can be used.

---

In reply to: 141783389 [](ancestors = 141783389)

[agocke]

Nice