Line length limit in F# - Bug or feature?

This code gives you an error in the error list of VS 2010:

let (a: float), (b: float), (c: int), (d: float), (e: float), (f: float), (g: float), (h: float), (i: float), (j: float), (k: float), (l: float), (abcdefghijklmnopqrstabcd开发者_开发问答efghijklmnopqrstabc: float ) = 0., 0., 0, 0., 0., 0., [], 0., 0., 0., 0., 0., 0., 0.

Adding one character to the last variable as

let (a: float), (b: float), (c: int), (d: float), (e: float), (f: float), (g: float), (h: float), (i: float), (j: float), (k: float), (l: float), (abcdefghijklmnopqrstabcdefghijklmnopqrstabcd: float ) = 0., 0., 0, 0., 0., 0., [], 0., 0., 0., 0., 0., 0., 0.

results in no error in the error list.

I have met such a behaviour in many ways but always in the long lines only. Is that a feature of F# or is it a bug?

Oldrich

The Visual Studio F# support cannot do errors and squiggles past column 255. If you look at the F# range type in the compiler sources, you can perhaps start to glean why (though I think it really should to go at least 511 chars); I don't remember for 100% sure right now exactly where the limitation lies.

(Incidentally, I only know this because I recently ran into it, see the comment at

https://github.com/brianmcn/FSharpDepthColorizer/blob/master/ParseTreeDepth/MyFSParser/MyParsing.fs

line 267.)

I am using VS2010 shell with the November CTP (not really sure whether this new CTP was built against .NET 2.0 or .NET 4.0)

I've tested this code in a various scenarios, and there is something a bit strange going on here. But certainly there are no "features" at work here, since as @Mauricio pointed out, both of these let-bindings are incorrect.

Interactive

Both give (almost) correct error to output:

Expecting a float * float * int * float * float * float * float * float * float * float * float * float * float but given a float * float * int * float * float * float * float * float * float * float * float * float * float * 'a The tuples have differing lengths of 13 and 14

Notice the "given" part of the error is wrong.

On-the-fly Error Detection Within VS Editor

Here I am seeing behavior similar to what you describe: I created two files Program.fs and Program2.fs with top-level modules test1 and test2 containing your first and second examples respectively. I get a red-squigly(sp?) with the same error message we had in FSI for the first, but no red-squigly for the second (and by toggling the 'd' character in the second I was able to induce the red-squigly).

Compiling

When attempting to build the project in the previous example, I get build errors for both let-bindings (same as what we see through FSI).

Conclusion

So it does look like there are two bugs (minor since we can't actually build the project) here:

1. The error message is incorrect
2. The in-editor error detection is inconsistent

Visual Studio provides the red squiggles and error navigation based on the position information returned from the F# compiler (fsc.exe). Unfortunately, as of VS2010 SP1, the F# compiler does not provide position information for errors in far right columns. You can see this in the Visual Studio Output Window. Normally an error shows up like this:

File.fs(60,213): error FS0001: This expression was expected ...

If the column isn't 213, but rather something larger (above 255 I think), the error is reported like this (and you get to have happy fun finding it):

File.fs: error FS0001: This expression was expected ...