Implement interpolated strings via String.Concat

[charlesroddie]

This PR implements comment, so that interpolated strings, where possible, are implemented via String.Concat. The benefits are:

• Performance (again comment, with perf measurements)
• Reflection-free, trimmable code that is NativeAOT compatible

There are some problems with the current implementation, and this PR takes a moderate approach, resolving some of them but retaining others to keep a broadly backwards-compatible implementation.

1. The type of an interpolated string is either string or PrintfFormat<...>. The latter is an unfortunate addition designed to allow expressions like printf $"...", working around the lack of print functions (fsharp/fslang-suggestions#1092). This should be marked obsolete when print functions are added.
2. Printf format expressions are allowed in holes. This creates:
   a) The parser handled these only partially: it left the specifier (e.g. %f) inside the preceding string component, leaving the compiler step to locate and process it. In this PR the specifier is split off and attached to its hole in a parser helper instead. So it's improved but still messy.
   b) Any hole with these expressions goes through the previous reflection-based route.
3. The rendering of strings was culture-dependent. This was likely unintentional since F# string functions like string are culture-independent. This is adjusted to match existing behaviour, using the string function. This is in keeping with similar changes that have moved towards string behaviour. (See the related discussion of string vs ToString behaviour in fsharp/fslang-suggestions#919.)
4. The previous syntax tree was faithful, allowing a hole formatted by both a printf specifier and a .NET alignment/format — which the language does not allow — to be expressed. This is adjusted to the following:

type SynInterpolatedStringPart =
    | String of value: string * range: range
    | FillExpr of fillExpr: SynExpr * formatting: SynInterpolationFormatting

type SynInterpolationFormatting =
    | DotNet of alignment: SynExpr option * format: Ident option
    | Printf of specifier: string * range: range

A NativeAOT test

A test under tests/AheadOfTime/NativeAOT (wired into the Windows trimming CI job) AOT-publishes a program that uses interpolation. Plain and .NET-format holes ({x}, {x:F2}, {x,6}) are AOT compatible. Printf-format holes (%d{x}) still route through sprintf, so they remain reflection-based and fail AOT with IL2026/IL2070/IL3050 — see the commented-out examples in the test.

This would be a good place to add other currently AOT-incompatible expressions for similar future fixes.

Notes on the LowerInterpolatedStringToConcat feature flag

This work extends and supersedes the work under the LowerInterpolatedStringToConcat flag, an "optimization that lowers string interpolation into a call to concat iff there are at most 4 string parts and all fill expressions are strings".

The reason why this feature was gated is unclear since it's just an optimization, but it's unclear what to do with this gate here. Options:

• Apply the behaviour in this PR unconditionally. This is what I would recommend as the behaviour change (matching string in culture-independence) is a fix to existing behaviour.
• Restore the existing LowerInterpolatedStringToConcat to apply to the current feature. The name is actually closer to the current feature than the previous gated feature. This would require keeping legacy code paths which if you ask me to do, I would re-add to a file clearly marked obsolete to keep current code clean.
• Add a new gate term. The ultra-bureaucratic solution.

[github-actions]

✅ No release notes required

[github-actions]

🔍 Tooling Safety Check — Affects-Build-Infra, Affects-Bootstrap, Affects-Compiler-Output, Affects-Test-Tooling
Affects-Build-Infra: new .fsproj with PublishAot, custom compiler paths, Versions.props import
Affects-Bootstrap: modifies pars.fsy grammar and core compiler checking
Affects-Compiler-Output: changes interpolated string lowering from printf to String.Concat
Affects-Test-Tooling: new check.ps1/check.cmd scripts wired into AheadOfTime CI suite

Generated by PR Tooling Safety Check · opus46 5.8M · ◷

[kerams]

%d and %s (unlike %.2f below) serve effectively only as a type annotation. Would it be difficult to identify this, strip the specifiers, and have these 2 lines also be lowered to concat?

[charlesroddie]

I assume the list is https://learn.microsoft.com/en-us/dotnet/fsharp/language-reference/plaintext-formatting, minus %a and %t.

The instructions for clean interpolated string usage could be "avoid format strings (Printf-style specifiers); use dotnet specifiers instead".

This could be modified to add "except you can use this whitelist" by doing what you suggest. It makes the instruction more complex so I wouldn't recommend that.

It could also be modified to "avoid using the %A printf-style format specifier" by working systematically through the list.

If these printf-style usages are important then going the whole way would be best.

[Numpsy]

I believe that the current implementation of the feature does already convert $"hello %s{name}" into string.Concat, so changing it so that it doesn't isn't an improvement?

[kerams]

@Numpsy, it applies only if every single hole is a string.

@charlesroddie, I was wrong in my assumption, it's not always just a type annotation :/

> $"{true}";;
val it: string = "True"

> $"%b{true}";;
val it: string = "true"

Guess we could still do it by replicating the run-time logic of printf, but maybe leave it out of this PR.

[Numpsy]

it applies only if every single hole is a string

Yes, my point was that the %s{name} case currently compiles into string.concat and doesn't produce any AOT warnings, but the comment here says it will produce warnings.