VS 2026 preview: FSI evaluation doesn't report correct line numbers

[smoothdeveloper]

related to #18907

in either .NET SDK and .NET Framework versions of FSI, submitting an evaluation seems to attribute the code to stdin with an ever increasing line number, rather than the location in the .fsx file from which the selection is being submited.

C:\Users\gauth\AppData\Local\Temp\stdin(124,15): error FS3033...

Also,
In VS 2026 preview, when using .NET Framework version of FSI, evaluating SOURCE_DIRECTORY yields "C:\Users\gauth\AppData\Local\Temp" rather than the directory containing the .fsx file being edited / evaluated.

[T-Gro]

I took this snippet and repeatedly sent it to fsi from VS

let printSourceLocation() =
    printfn "Line: %s" __LINE__
    printfn "Source Directory: %s" __SOURCE_DIRECTORY__
    printfn "Source File: %s" __SOURCE_FILE__
printSourceLocation()

In VS2026 as well as VS2022 (17.14preview), I get the ever increasing line number.

> Line: 8
Source Directory: D:\source\Scratchpad
Source File: stdin
val printSourceLocation: unit -> unit
val it: unit = ()

> 
Line: 22
Source Directory: D:\source\Scratchpad
Source File: stdin
val printSourceLocation: unit -> unit
val it: unit = ()

In VS2019 (with .NET5 SDK) I get the expected behaviour:

> Line: 6
Source Directory: D:\source\Scratchpad
Source File: Program.fs
val printSourceLocation : unit -> unit
val it : unit = ()

> 
Line: 6
Source Directory: D:\source\Scratchpad
Source File: Program.fs
val printSourceLocation : unit -> unit
val it : unit = ()

> 
Line: 6
Source Directory:  D:\source\Scratchpad
Source File: Program.fs
val printSourceLocation : unit -> unit
val it : unit = ()

[T-Gro]

VS.FSI could in theory prepend line like this:
#line 42 "C:\path\to\file.fsx" to every submission.

My fear is that this line would leak somewhere (such as in the output) which would be a bigger regression (in terms of users affected) compared to to the SOURCE directives.

[T-Gro]

Oh well, a #line is already there, I wonder if this could be consequence of the bugfixing @Martin521 did w.r.t. to #line handling.
The directive is added below the submission, but maybe has an effect nevertheless?
But since a bunch of code is already added around every submission, the worries about it not leaking can be lifted I assume.

fsharp/vsintegration/src/FSharp.VS.FSI/fsiSessionToolWindow.fs

Lines 549 to 559 in 041a528

	let executeInteraction dbgBreak dir filename topLine (text:string) =
	let interaction() = $"""
	{ hide()}
	#silentCd @"{dir}";;
	{if dbgBreak then "#dbgbreak" else ""}
	# {topLine} @"{filename}"
	{text.ToString()}
	;;
	# 1 "stdin"
	{ show()};;
	"""

[Martin521]

I am afraid this is due to #18699 , where we announced the breaking change regarding __LINE__ and __SOURCE_FILE__ .
Note that error and warning messages show the correct line.

@smoothdeveloper:
Did you just find this accidentally, or do you have a use case that needs it?

[T-Gro]

@Martin521 : You are the expert on the system now, is there anything we can add in the system generated wrappers (see above) that would make __LINE__ and __SOURCE_FILE__ work as expected?

Right now it sends just # {topLine} @"{filename}", I assume replacing that with #line ... will not have an effect (or would it?)

This is created before the interaction is parsed, so we might consider passing data long the side.

[Martin521]

I think that line is ok. It creates correct line numbers for diagnostic messages, debugging, caller info etc.

The problem is that __LINE__ etc are set during lexing, while the new range.ApplyLineDirectives() is only available once lexing/parsing is completed for the file. At the time, we did not see use cases that use __LINE__ etc AND would be interested in something else than the real line number of the compiland. Except for compiler-related tools that can apply range.ApplyLineDirectives() themselves. Therefore we accepted the breaking change.

That's why I am interested in the use case.

[T-Gro]

It's submissions coming from VS.FSI - what if they use a dedicated preprocessor step (or maybe only after a naive detection of the SOURCE and related directoves) and pre-feed the line map, could that work?

[Martin521]

Well, the line map for the submission (file) does not exist yet at that point. It is only created in post-parse.

In general, processing the directives (all of them) in a pre-processing step rather than during lexing and parsing would make a lot of sense (not only for fsi, but always). It could simplify a lot of code (lex.fsl, for example, would shrink to half of its current size). But, it is also a BIG change.

I believe that for the specific issue of #line + __LINE__, there are simpler solutions to remedy the breaking change (if there are use cases that make the work worthwhile). But it needs some deeper investigation.