Improve diagnostics for inlining in class methods - FS1114, FS1113, FS1116, FS1118

[abelbraaksma]

The general rule in F# let-bindings is that they must appear in order if they are dependent on one another, but inside classes, and among classes chained with and , the order is irrelevant.

Most of the time this is true, but if you use inlined members and these are forward-declared in your class or class hierarchy, they may lead to spurious compile-time errors. These errors (see below) are generally only raised when using inlining on recursive functions, leading to very hard-to-diagnose uncompilable code. Besides, these errors are not only misplaced, they seem to be plain wrong, there should probably not be an error at all.

Repro steps

Over the cause of a few weeks analyzing this, leading to a first and a second yet to be answered StackOverflow question, it suddenly dawned to me that rearranging the members solved the problem. But first things first, here's how to repro.

First example (copy/paste and compile to see the error)

/// Does a bounds check and raises an error if bounds check is not met
let inline checkBounds f (g: 'b -> ^c) (tp: ^a) = 
    let convertFrom = (^a: (static member name: string) ())
    let convertTo = (^c: (static member name : string) ())
    let value =  (^a: (member Value: 'b) tp)
    if f value then
        g value
    else 
        failwithf "Cannot convert from %s to %s." convertFrom convertTo


type ConverterA =
    struct 
        val Value: sbyte
        new v = { Value = v }
    end

    static member inline name with get() = "converter-a"
    static member inline convert (x: ConverterA) : ConverterB = 
        checkBounds ((>=) 0y) (byte >> ConverterB) x

and ConverterB =
    struct 
        val Value: byte
        new v = { Value = v }
    end
    static member inline name with get() = "converter-b"

Second example:

[<Flags>]
type MyType =
    | Integer = 0b0001
    | Float   = 0b0010

module Test =
    [<CustomEquality;NoComparison>]
    type SomeType =
        | Int of int64
        | Float of float

        override x.Equals other =
            match other with
            | :? SomeType as y -> 
                // following line throws on compiling this
                match SomeType.getType x &&& SomeType.getType y with
                | MyType.Integer -> int64 x = int64 y       // highest type is integer (both are int)
                | MyType.Float -> float x = float y         // highest type is float (either is or both are float)
                | _ -> false // impossible
            | _ -> false

        override x.GetHashCode() =
            match x with Int i -> hash i | Float f -> hash f

        static member inline op_Explicit(n: SomeType): float =
            match n with
            | Int i -> float i
            | Float f -> f

        static member inline op_Explicit(n: SomeType): int64 =
            match n with
            | Int i ->  i
            | Float f -> int64 f

        static member inline getType x =
            match x with
            | Int _ -> MyType.Integer
            | Float _ -> MyType.Float

Third (simplest I could muster) example:

module Test =
    type SomeType =
        | Int of int64
        | Float of float

        static member MyEquals (x, other: SomeType) =
            // following line throws on compiling this
            float x = float other 

        static member inline op_Explicit(n: SomeType): float =
            match n with
            | Int i -> float i
            | Float f -> f

        static member inline op_Explicit(n: SomeType): int64 =
            match n with
            | Int i ->  i
            | Float f -> int64 f

(these examples are also used in the SO questions)

Expected behavior

While typing these examples, the syntax checker and inference algorithms won't show any errors. When you compile them, the expected behavior is that they compile just fine (apart from perhaps debatable practices of the code examples, but I had to simplify, they originate from a large codebase).

Actual behavior

Instead of compiling just fine, the following errors and warnings are raised by the compiler (and the variants thereof for each example above, but the error numbers and order wherein they appear are the same).

error FS1114: The value 'Foo.Bar.name' was marked
inline but was not bound in the optimization environment

error FS1113:The value 'name' was marked inline but its
implementation makes use of an internal or private function which is not
sufficiently accessible

warning FS1116: A value marked as 'inline' has an unexpected value

error FS1118: Failed to inline the value 'name'
marked 'inline', perhaps because a recursive value was marked 'inline'

Note that the errors seem to point out that it fails to inline the following method, which itself has no dependencies and seems trivial to inline:

static member inline name with get() = "converter-b"

Note also that FS1113 is not applicable at all, there are no private or internal members or functions.

Note that FS1116 is incomprehensible (how can an inline function have an unexpected value? What is it? And what is the value?)

Note that FS1118 suggests it is a recursive function marked inline. This is the only error that hints that the compiler has not enough knowledge to inline the method, but hints in the wrong direction (there is nothing recursive).

This gets worse when you have a compilable codebase and you decide, for instance, to implement override x.Equals(), or IComparable. It is common practice to place these on top. But if they call into inline functions you suddenly get those errors. And I've found that they can appear in related classes, not even in the just-added methods, which furthers the troubles of diagnosing this.

Known workarounds

Changing the order in which the class members, or classes themselves appear solves the problem. Though this is, I believe, against the policy that inside a class the order ought to be insignificant. An example of a compilable version of repro 2 above:

/// Does a bounds check and raises an error if bounds check is not met
let inline checkBounds f (g: 'b -> ^c) (tp: ^a) = 
    let convertFrom = (^a: (static member name: string) ())
    let convertTo = (^c: (static member name : string) ())
    let value =  (^a: (member Value: 'b) tp)
    if f value then
        g value
    else 
        failwithf "Cannot convert from %s to %s." convertFrom convertTo

// place ConverterB before ConverterA solves the error
type ConverterB =
    struct 
        val Value: byte
        new v = { Value = v }
    end
    static member inline name with get() = "converter-b"

and ConverterA =
    struct 
        val Value: sbyte
        new v = { Value = v }
    end

    static member inline name with get() = "converter-a"
    static member inline convert (x: ConverterA) : ConverterB = 
        checkBounds ((>=) 0y) (byte >> ConverterB) x

Related information

The examples above fail to compile with VS2015, Update 1, 2 and 3, using F# 4.0 (FSharp.Core 4.4.0.0).

I consider this issue relatively severe because the errors raised have so little to do with the actual situation and can appear "out of nowhere" after you add a simple new method. Even if an error is legit in this case, something like "Method X is unknown, but exists in your declarations, consider changing the order in which they appear in the source so that the optimization environment can bind to them."

BTW, there are many situations where the order of inlined functions does not matter, leading to situations where you have compilable code that just, after adding an otherwise independent method, stops being compilable.

[dsyme]

@abelbraaksma Thanks for the analysis and detailed repros.

Though this is, I believe, against the policy that inside a class the order ought to be insignificant.

Just to note that the order is definitely significant for inlining between members, as your examples show. But the error messages definitely are sub-par in this case.

[abelbraaksma]

Thanks for your quick response.

I've been trying on MSDN and the F# 4.0 language spec to find out where it states that the order inside a class (between members) is important w.r.t. inline members.

Experimenting myself shows that sometimes it is and sometimes it isn't. Or put in another way, I can't deduct the apparent rules from just experimenting alone.

For instance, in the following example, A() and B() are normal members and they don't seem to care about order. But test() does matter, if I place it one or more lines up, it gives the earlier mentioned errors. Then again, add a b does not have any problem here, even though its dependent on definitions of op_Explicit that are defined below it.

type SomeType =
    | Foo
    | Bar
    static member inline add a b = int a + int b
    static member inline op_Explicit(n: SomeType): float = 2.
    static member inline op_Explicit(n: SomeType): int = 2
    static member test() = SomeType.add SomeType.Foo SomeType.Bar

    static member B() = SomeType.A()
    static member A() = 3

In several online sources it is explained that the order of members inside classes, and between classes when chained with and, doesn't matter. But none of them are specific about inline or mention it as a special case that must be ordered. Well, I mean to say, I couldn't find it, that doesn't mean it isn't out there, specified somewhere.

[abelbraaksma]

Mmm, letting this sink in a bit more, it seems to me that the general rule is that any inline member of a class must be declared prior to its usage, that is, the moment the inlining materializes.

// successful compilation
static member B() = OtherType.A()
static member A() = 3
static member inline C() = OtherType.B()

Then, order between inline members is important when they are "normal" (i.e., have no member constraints):

// fails to compile with FS1113, FS1114 etc
static member inline B() = OtherType.A()
static member inline A() = 3

With member constraints (here (+)), order seems less important, but I think that is simply because the type, until the method is actually used, is not known, so nothing gets compiled (except for the stubs):

// no error, even though `add` is dependent on `(+)`
static member inline add a b = a + b
static member inline (+) (a, b) = 3 + 4

All in all, there seems to be some logic, esp. if you try to think as a compiler. And if that's the status-quo and intent of how it is supposed to work I have no problem with that (apart from the already mentioned clarity of the errors, of course ;).

[dsyme]

@abelbraaksma Yes, good summary. Certainly neither the language spec nor MSDN is clear about this. Could you submit a clarification to the MSDN docs please? (which are open source now).

[abelbraaksma]

@dsyme: it appears I never acted on your request for updating the docs, but I think we can close this issue, with VS2017 I cannot repro this anymore given the examples in the original post (I tried all four of them), hurray!!! This moots the requirement for updating the docs.

And much to my surprise, apparently the fix applies to both F# 4.0 as well as F# 4.1. Not sure what actual PR solved this one, but this could be placed on the list of achievements: order of declarations in classes does not lead to compile errors anymore!

[dsyme]

@abelbraaksma Thanks for checking all these old issues so thoroughly

I don't recall a specific change that would have fixed this - but I will close it since you have validated that it is fixed

[abelbraaksma]

@dsyme, I think we should reopen this. I must have incorrectly tested it. Try the first example in VS2017:

• no error when loaded
• errors when compiled as described

This report by @vasily-kirichenko reminded me that this old bug isn't fixed yet. #3634.