2

Closed

Inlining breaks PCL-defined methods in normal assemblies

description

Closed Oct 24, 2014 at 12:12 AM by latkin

comments

dsyme wrote Oct 3, 2014 at 8:50 PM

I agree this is a bug in our Profile7/259 PCL story.

The best workaround for those using F# 3.1 is to turn off cross-assembly inlining for any F# portable assemblies using "--nooptimizationdata".

The best and simplest fix for future versions of the compiler is almost certainly to change the definitions of tspec_is_primaryAssembly
            https://github.com/fsharp/fsharp/blob/20a9d20e7a3752244b03f62147e453db748a08eb/src/absil/il.fs#L2850
to look for assembly name mscorlib OR System.Runtime. In reality both should be considered “special” primary assembly names for the purposes of F# compilation and especially for emitting valid IL code.

It would be great to get a fix in the queue.

The bug here is that we emit a reference to “int32” as
            [System.Runtime]System.Int32
Instead of
            int32
in

IL_0009: call instance valuetype [System.Runtime]System.Int32 [System.Runtime]System.DateTime::get_Year()

latkin wrote Oct 24, 2014 at 12:12 AM

Fixed with 3a38b7ae87d7

StephenSwensen wrote Jul 9, 2015 at 2:55 AM

Question: does this this issue only affect normal assembly projects that are compiled with a reference to a PLC project (as with the reproducing example), or will this affect normal assembly projects that reference an already compiled PCL dll?

i.e. if I am currently distributing and Profile 259 PCL, should I take action to instead distribute a Profile 47 PCL as per the guidelines at http://fsharp.github.io/2015/04/18/fsharp-core-notes.html?

dsyme wrote Jul 9, 2015 at 11:37 AM

If making and distributing PCLs with F# 3.1.x, the recommendation is to make a Profile47 component (because of this bug).

You can consume any PCLs built with C#