Measure-generic structs wrongly can't be treated as unmanaged

This issue is described here. Given this type definition:

[<Struct>] 
type vec3<[<Measure>] 'u> = 
   val mutable X: float<'u> 
   val mutable Y: float<'u> 
   val mutable Z: float<'u>

the F# compiler won’t allow vec3<_> to satisfy the unmanaged type constraint because it’s “generic”, even though it isn’t really generic in the CLR sense (since measure type arguments are erased at runtime):

 // error FS0001: A generic construct requires that the type 'vec3<1>' is an unmanaged type
 let ptr = NativeInterop.NativePtr.ofNativeInt<vec3<1>> 0n

[zpodlovics]

Similar but non measure generic case for struct with measurement fields: #276 which was fixed in #289

open System.Runtime.InteropServices

[<Measure>]
type Version

[<Struct>]
type S =
  val X: int

[<Struct>]
type SM =
  val X: int<Version> 

[<Struct>]
type SMG<[<Measure>] 'u> =
  val X: int<'u> 

[<Struct; StructLayout(LayoutKind.Sequential, Pack=1)>]
type SS =
  val X: int

[<Struct; StructLayout(LayoutKind.Sequential, Pack=1)>]
type SMS =
  val X: int<Version> 

[<Struct; StructLayout(LayoutKind.Sequential, Pack=1)>]
type SMGS<[<Measure>] 'u> =
  val X: int<'u> 

let f (x : 'T when 'T: unmanaged and 'T: struct) = printfn "%A" x

f (S())
f (SM())
//f (SMG()) // FS0001: A generic construct requires that the type 'SMG<'u>' is an unmanaged type
//f (SMG<Version>()) // FS0001: A generic construct requires that the type 'SMG<Version>' is an unmanaged type
f (SS())
f (SMS())
//f (SMGS()) // FS0001: A generic construct requires that the type 'SMGS<'u>' is an unmanaged type
//f (SMGS<Version>()) // FS0001: A generic construct requires that the type 'SMGS<Version>' is an unmanaged type

printf "is SMG<Version> a generic type: %A\n" (typeof<SMG<Version>>.IsGenericType)
printf "is SMG<Version> a value type: %A\n" (typeof<SMG<Version>>.IsValueType)

Note if you use it for native interop: Blittable types are a subset of unmanaged types where the type have same managed and unmanaged representation.

Ecma 355 II.10.1.2 Type layout attributes

“[Rationale: The default auto layout should provide the best layout for the platform on which the code is executing. sequential layout is intended to instruct the CLI to match layout rules commonly followed by languages like C and C++ on an individual platform, where this is possible while still guaranteeing verifiable layout. explicit layout allows the CIL generator to specify the precise layout semantics. end rationale]”

[kbattocchi]

@zpodlovics See issue #654, which is being fixed by #656.