Support CallerArgumentExpression (without #line)

[ijklam]

Description

Implements fsharp/fslang-suggestions#966

RFC fsharp/fslang-design#798

Checklist

• Test cases added
• Performance benchmarks added in case of performance changes
• Release notes entry updated:

[github-actions]

❗ Release notes required

---

✅ Found changes and release notes in following paths:

Change path	Release notes path	Description
src/Compiler	docs/release-notes/.FSharp.Compiler.Service/9.0.300.md
LanguageFeatures.fsi	docs/release-notes/.Language/preview.md

[ijklam]

Here I encounter a problem about #line. For example, the code is saved in D:\Program.fs:

#1 "C:\\Program.fs"
System.ArgumentNullException.ThrowIfNullOrWhiteSpace("   ")  // will failed to build

// And more complicated case, repeat the file name and line number
#1 "C:\\Program.fs"
System.ArgumentNullException.ThrowIfNullOrWhiteSpace("   ")  // will failed to build

So here I want to get the original range instead of a range modified by #line . Is there anybody know how to do it?

[brianrourkeboll]

I wonder whether it would be possible to use ISourceText.GetSubTextString instead of all of this. I think the ISourceText for a given file will usually already be cached when this functionality is needed.

I think in theory the source text is available on cenv.tcSink.CurrentSink.Value.CurrentSourceText.Value, but maybe there's a better way to get it, or a better way to bring it in scope for this change.

[ijklam]

It seems that this cannot work under dotnet fsi and under dotnet build. It is always None.

[brianrourkeboll]

Maybe it would make sense to pass it in, then, as is done when checking format strings:

fsharp/src/Compiler/Checking/NameResolution.fs

Lines 1777 to 1779 in 0a715a5

	type FormatStringCheckContext =
	{ SourceText: ISourceText
	LineStartPositions: int[] }

fsharp/src/Compiler/Checking/CheckFormatStrings.fs

Lines 67 to 73 in 0a715a5

	let makeFmts (context: FormatStringCheckContext) (fragRanges: range list) (fmt: string) =
	// Splits the string on interpolation holes based on fragment ranges.
	// Returns a list of tuples in the form of: offset * fragment as a string * original range of the fragment
	// where "offset" is the offset between beginning of the original range and where the string content begins
	let numFrags = fragRanges.Length
	let sourceText = context.SourceText

[brianrourkeboll]

Maybe it would make sense to pass it in, then, as is done when checking format strings:

I guess maybe that's the same source text as in the sink... But still, maybe there's somewhere else we could put it.

[Martin521]

I feel uneasy with this module.

• It adds a global resource for a rather local feature.
• It creates another dependency on the file system.
• It re-reads sources from the file system that have been read before.

Getting the source text out of the checking environment as proposed by @brianrourkeboll would be much cleaner.
A (probably too ambitious) alternative would be to make this a central place for source access, to give ISourceText the role that it was meant to have and to remove file system access elsewhere.

[ijklam]

Hi there, I've make some efforts to make it get the source code from the LexBuffer and pass it to the cenv. Now it won't read files twice, and some parser functions in ParseAndCheckInputs.fs now return ParsedInput * ISourceText option, some checker functions also need a ISourceText option as input.
I created a new field cenv.SourceText: ISourceText option besides the cenv.tcSink.CurrentSink.CurrentSourceText to store the source content, as the cenv.tcSink is seems to be used only in language service scenario.

[T-Gro]

Put data to rest of the fields above of this type.
The style here is - declaration, fields, private let functions, then members.

Make it obvious by design that the StringBuilder is being cleared when appropriate (where does buffer cleanup happen now when lexes moves to a different file?)

[T-Gro]

Consider either pooling of the StringBuilder instances or a starting buffer that would reflect average size of an F# source file (the buffer above uses 4096 for example)

[T-Gro]

Consider: Existing mechanism via TryFindFSharpAttribute and having a reference to the attribute in TcGlobals, i.e. work on strongly typed referenced to attribute definitions and not on strings.

[T-Gro]

Wouldn't approach like this one work here:

let compiledNameAttrib = TryFindFSharpStringAttribute g g.attrib_CompiledNameAttribute attrs

[T-Gro]

Is there a particular reason for all added tests being FactForNETCOREAPP and not Fact that would also test Desktop framework?

[T-Gro]

For future maintainers, I think this test setup needs more explanation of the context.

[T-Gro]

Did you consider a de-generate scenario of a huge file being a single expression (e.g. a massive collection builder, or a massive async block) passed into a single CallerArgumentExpressionAttribute member?