Compiler error "Incorrect number of type arguments to local call"

Question

I'm running into the compiler error "Incorrect number of type arguments to local call" when using custom types with unit-of-measure type arguments, and I do not understand why.

This question has undergone quite a few edits. It looks likely now that the error is caused by a compiler or IDE bug.

I could narrow it down to the following (read the points below when trying to reproduce):

type R<[<Measure>] 'u> (f : float<'u>) =
    member r.Member = f

let get (r : R<_>) = r.Member
let foo =
    let problem _ = List.map get
    problem // Error: Incorrect number of type arguments to local call

The last line gives the error, which is especially weird, since it is doing nothing more than returning an already-defined identifier. I am compiling to a library or executable. Some important observations for reproduction:

• IntelliSense does not predict this error. An actual compilation is required to see it.

• I haven't yet seen the error when compiling with optimization. (For reproduction, use e.g. the default debug compile in Visual Studio. Thanks to zapu on Freenode for pointing this out.)

• I haven't yet seen the error in F# interactive.

• Removing the useless parameter of problem (the _) makes the error disappear.

• Moving the let-binding of problem out of foo makes the error disappear. Might this be related to compilation as an F# function? I heard that this is indicated by additional parentheses around the type of problem.

• Removing the unit-of-measure usage makes the error disappear.

• Marking problem as inline makes the error disappear.

A lot of seemingly irrelevant changes remove the error. But it isn't that easy in the actual use case, especially when I don't know whether a change fixes the error before I try it.

I'd be happy about any hints on this. What causes it? Is it a bug, and if so, is it known? How can it be avoided?

Versions This was tested with versions from 3.0 to 3.1.2 of F#. I installed the new Visual Studio 2013 Community edition and tested with the version it supplied, with the same result. It also occurs in Visual Studio 2012 (F# 3.0).

Update: I've asked others to test this, and the behavior can often be reproduced in Visual Studio 2012 or 2013.

Answer 1

This was indeed a bug. I reported it and it was fixed on 2015-01-30 by Andrew Kennedy; see this issue report for Visual F# on Github.

Funny side-effect: the absurd code from this question ended up as a regression test. (It is hereby public domain, just in case)

Future releases of F# should no longer have this issue. Thanks to everyone who helped reproduce, analyze, and repair it!