Roslyn: Please clarify the implementation details of unmanaged generic constraints

Created on 5 Jun 2018  路  6Comments  路  Source: dotnet/roslyn

_From @gfraiteur on June 5, 2018 15:57_

Given the following C# code:

 unsafe struct MyUnmanagedStruct<T,U,V> 
        where T : unmanaged
        where V : unmanaged

We get the following MSIL code:

.class private sequential ansi sealed beforefieldinit TestUnmanagedConstraint.MyUnmanagedStruct`3
< valuetype .ctor (class [System.Runtime]System.ValueType  modreq([System.Runtime.InteropServices]System.Runtime.InteropServices.UnmanagedType)) T,
   U,
   valuetype .ctor (class [System.Runtime]System.ValueType modreq([System.Runtime.InteropServices]System.Runtime.InteropServices.UnmanagedType)) V
 >  extends [System.Runtime]System.ValueType
{
  .param type T 
  .custom instance void System.Runtime.CompilerServices.IsUnmanagedAttribute::.ctor() = ( 01 00 00 00 ) 
  .param type V 
  .custom instance void System.Runtime.CompilerServices.IsUnmanagedAttribute::.ctor() = ( 01 00 00 00 ) 
} 

There are two distinctive characteristics of unmanaged constraints: the UnmanagedType custom modifier, and the IsUnmanagedAttribute custom attribute.

I'm updating the generic constraint resolution logic in PostSharp and I would need to know:

  • Which artefact signals the presence of an unmanaged constraint? The modreq, the custom attribute, or both?

  • I assume that an unmanaged type is any value type (not reference type) that has only fields of unmanaged type. For fields of generic types, we would then look at the unmanaged constraint.

  • Are there planned breaking changes in the runtime that we should know of, so we avoid the wrong code generation patterns?

Thanks.

_Copied from original issue: dotnet/corefx#30148_

Area-Compilers Documentation Question Resolution-Answered

Most helpful comment

@gfraiteur

  • both modreq and attribute has to exist. We don't import symbols that have only one. We produce error CS0570: 'T' is not supported by the language in such cases.
  • The notion of "unmanaged" types didn't change with this feature. Any type that you can take a pointer to is unmanaged. The feature enables you to enforce that notion on type parameters.
  • Runtime has no support for this. It is purely a C# construct.

Please let me know if I can provide any more info.

All 6 comments

The unmanaged constraint is a pure C# language construct. This issue should better be in Roslyn repo.

Runtime is not aware of the unmanaged constraint. I am not aware of any plans to fix it.

cc @OmarTawfik @jaredpar

@gfraiteur Related: #1504 ?

Thank you. I understand therefore that the runtime ignores any custom modifier on type generic constraints and we need to make sure we also ignore them.

@gfraiteur

  • both modreq and attribute has to exist. We don't import symbols that have only one. We produce error CS0570: 'T' is not supported by the language in such cases.
  • The notion of "unmanaged" types didn't change with this feature. Any type that you can take a pointer to is unmanaged. The feature enables you to enforce that notion on type parameters.
  • Runtime has no support for this. It is purely a C# construct.

Please let me know if I can provide any more info.

Thank you. I didn't notice previously that the notion of "unmanaged" type is a compiler one, and the runtime actually lets you take a pointer to anything.

Was this page helpful?
0 / 5 - 0 ratings