You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
byref analysis not working with type abbreviations #7934
Consider the following example involving a ReadOnlySpan and a type abbreviation:
openSystemtypeBytes= ReadOnlySpan<byte>typeFoo()=//member this.foo1 (data: ReadOnlySpan<byte>) =// let x = // if false then// failwith "" // Error FS0412: A type instantiation involves a byref type. This is not permitted by the rules of Common IL// else// data// x//member this.foo2 (data: ReadOnlySpan<byte>) =// let x = // if false then// failwithf "" // Error FS0412: A type instantiation involves a byref type. This is not permitted by the rules of Common IL// else// data// xmemberthis.foo3(data:Bytes)=letx=iffalsethen// true or false doesn't matter
failwith ""else
data
x
memberthis.foo4(data:Bytes)=letx=iffalsethen
failwithf ""else
data
x
[<EntryPoint>]letmain argv =letspan= ReadOnlySpan<_>(Array.empty)letresult= Foo().foo3(span)letresult= Foo().foo4(span)0
Repro steps
As described in #5776 the functions foo1 and foo2 give a compiler error. However, if I use a type abbreviation instead of the actual name of the byref-type ReadOnlySpan the compiler errors disappear and the program can be compiled. The funtion foo3 even works despite it shouldn't, at least I suppose. foo4 raises a TypeLoadException:
System.TypeLoadException: 'The generic type 'Microsoft.FSharp.Core.PrintfFormat`5' was used with an invalid instantiation in assembly 'FSharp.Core, Version=4.7.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.'
Expected behavior
None of the above functions should compile. I'm not sure why foo3 works at runtime anyway.
Actual behavior
A type abbreviation kind of prevents the byref analysis which leads to bad surprises at runtime.
Activity
cartermp commentedon Dec 4, 2019
link #6133
(related, but not the same issue)
TIHan commentedon Dec 10, 2019
Yes, this should fail at compile time. Thank you for making an issue. It should be an easy fix.
This is because
failwithis inline and doesn't use a byref-like type as a type argument in its internals.cartermp commentedon Dec 17, 2019
Fixed by #7953