Fix public surface to match CoreCLR

[jkotas]

No description provided.

[weshaggard]

Any idea why TypedReference is still showing up as not ref in the ProjectN we are consuming in corefx?

[jkotas]

@dotnet-bot test Ubuntu Debug and CoreCLR tests please
@dotnet-bot test Ubuntu Release please

[jkotas]

It is expected that that TypedReference is ref in ProjectN CoreLib.

It is logical ref in CoreCLR CoreLib as well, except that it is not marked as such in metadata. The type loader is special casing it as ref for historic reasons.

[weshaggard]

So you don't expect that we will never remove this baseline https://github.com/dotnet/corefx/blob/master/src/System.Runtime/src/ApiCompatBaseline.uapaot.txt#L1 because we cannot mark it as ref in the contract?

[jkotas]

@dotnet/dnceng Is there a problem with the Ubuntu machine pool? This PR is waiting for Ubuntu machines for 15+ hours...

[mmitche]

@jkotas We ran over the deployment limit somehow. I'm looking into it.

[jkotas]

So you don't expect that we will never remove this baseline https://github.com/dotnet/corefx/blob/master/src/System.Runtime/src/ApiCompatBaseline.uapaot.txt#L1 because we cannot mark it as ref in the contract?

RuntimeArgumentHandle (and ArgIterator - not in .NET Core today) would be in the same category. It was missing the ref marker - I am fixing this here.

This compact hack has to be somewhere. The alternative would be to have it in the runtimes.

We need this compat hack because of the C# has not reconciled handling of these 3 legacy ref-like types with the new ref-like feature. So yet another alternative would be to do something about that, e.g. accept the source-breaking change in the few corner where it is causing problems for .NET Core and mark them ref-like in the .NET Core contracts.

cc @VSadov

[VSadov]

C# compiler already treats "legacy" byref structs as ref structs, regardless if they are decorated with ref or not.

That is not a problem since the restrictions on those types were stronger than on the new ref structs. And in places where the constraints are stronger they are still enforced. (I.E. I think you cannot return them from a method or pass by ref at all, regardless of escape analysis).

The only place that we had to adjust is to not poison these types with Obsolete if they do become ref structs in the source, since poisoning would be breaking for existing types.
See - dotnet/roslyn#22275
This was done specifically so that you could make them ref in source, if you want to contain ByReference<T> which makes sense to do in coreclr.

I am not aware of anything else missing regarding handling of TypedReference and friends.

[VSadov]

I.E. - I think it would be optional, but convenient for you to make these structs ref structs on all runtimes and that should not be breaking, since they are already treated as such.

[VSadov]

LGTM

[VSadov]

CC: @jaredpar

[jkotas]

I.E. - I think it would be optional, but convenient for you to make these structs ref structs on all runtimes and that should not be breaking, since they are already treated as such.

Cool. I did not know that. So we should just mark them as ref in CoreCLR and contracts as well.