This is repeated several times. Consider extracting a helper method. #Resolved

public

Is the public qualifier needed? #Resolved

IsManagedTypeHelper

Consider use a top-level class and make this an extension method. #Resolved

Consider use a top-level class and make this an extension method.

I prefer to keep the code as is. I do not foresee us using this helper much in the future. Therefore, in my opinion there is no good reason to "pollute" name lookup binding space with it. If we could use Default Interface Implementations feature in our code, I would make this method a member of INamedTypeSymbolInternal.

IsManagedType

GetManagedKind()? #Resolved

GetTupleUnderlyingTypeOrSelf()

Are we testing a case where this call makes a difference? #Resolved

Are we testing a case where this call makes a difference?

I cannot think of a situation when it would make an observable difference in behavior. That is not to say that that it is impossible to run into one in some edge error scenario. Given the difference in the way C# and VB compilers represent tuple symbols, I prefer to be conservative and explicitly unwrap tuple types.

namedTypeSymbol.Arity = 0 AndAlso

It looks like the C# version and related C# extension methods are not checking Arity == 0. Should we add that check to those methods? #Resolved

Indeed, added a test and opened an issue to follow up - #75681

End Sub

Are we testing type parameters?

Sub M1(Of T1, T2 As Class, T3 As Structure)(t1 as T1, t2 As T2, t3 As T3)
    Dim o As New Test
    o.M(t1)
    o.M(t2)
    o.M(t3)
End Sub
``` #Resolved

Are we testing type parameters?

Type parameters are covered in UnmanagedCheck_TypeParameter and indirectly on several other tests.

Assert.Equal

Check S3 and S4 as well? #Resolved

I don't think we actually need the Volatile.Read; the memory barrier from ImmutableInterlocked.InterlockedInitialize in ResolveConstraints should prevent writes to _lazyHasIsUnmanagedConstraint from being reordered after writes to _lazyConstraintType, and EnsureAllConstaintsAreResolved won't skip calling ResolveConstraints unless this thread has already observed that _lazyConstraintType has been initialized. And if the ordering in that method ever changes (ie, the write to _lazyConstraintType is moved before the write to _lazyHasIsUnmanagedConstraint), then this Volatile.Read won't actually help anyways. #Resolved

I prefer to keep the Volatile.Read. The "distance" between this operation and the interlocked exchange is several method calls and some of them are virtual calls. In one of the methods we check value of _lazyConstraintTypes without any memory barrier operation in the same body. Assuming that that read and this _lazyHasIsUnmanagedConstraint can be reordered, we might see the old value of _lazyHasIsUnmanagedConstraint here while the _lazyConstraintTypes check in EnsureAllConstraintsAreResolved sees the new value of _lazyConstraintTypes. If that is too paranoid, that is fine with me, Volatile.Read won't make things worse.

Assuming that that read and this _lazyHasIsUnmanagedConstraint can be reordered, we might see the old value of _lazyHasIsUnmanagedConstraint here while the _lazyConstraintTypes check in EnsureAllConstraintsAreResolved sees the new value of _lazyConstraintTypes.

The issue with this reasoning is that that is not what Volatile.Read does. Volatile.Read prevents any reads or writes after the read from being ordered before this read. It does not prevent reads that occur before this read from being reordered to after this read. If that is your concern, you would need Thread.MemoryBarrier() in between the method call and the read of _lazyHasIsUnmanagedConstraint.

I remain unconvinced. The documentation says: "Reads the value of the specified field." That is exactly what I am going after. The call reads the specified address. I am not concerned about what happens before or after the call. I am concerned about that specific read happening exactly when the call is executed. Not before the call, not after the call.

Alright, after some extensive offline conversation here, I've opened #75759 to follow up on the race condition here; given that it's present in C# version as well, and has been present for a while, I'm going to approve for now, but we'll be following up on this next week to discuss a better long-term approach for the compiler.

Please add the new language version and feature in:

• https://github.com/dotnet/vblang/blob/main/Language-Version-History.md
• https://github.com/dotnet/roslyn/blob/main/docs/Language%20Feature%20Status.md

Is there an explanation as to what this enables VB to do?