Compiled ToStrings under -reflectionfree for DUs and Records

[charlesroddie]

This PR implements ToString on user-defined DUs and records, under the --reflectionfree switch, by delegating into the equivalent of LanguagePrimitives.anyToStringShowingNull, as is currently used by Option. Previously only the type name was shown. The new ToString is AOT/trim friendly, provided that the inner types have AOT/trim-friendly ToString methods.

It also implements ToString on Result and Choice types, and consolidates behaviour to match Option.

Fixes fsharp/fslang-suggestions#919

Behavioural changes (ungated)

• WIP: Explicit ToStrings on FSharp.Core types are being discussed in a thread below.

Behavioural changes (subject to --reflectionfree)

• Records and DUs now generate real ToStrings instead of just the type name. The behaviour matches Option for the internal rendering, and this differs from non-reflection-free mode (sprintf "%+A") in the following ways:
  • The floating point number 5. renders as 5.
  • Records render on a single line, avoiding the complex indentation logic in sprintf "%A".
  • Anonymous records render with {| ... |} syntax instead of { ... }

While the exact code of Option couldn't be used directly (since anyToStringShowingNull is internal to FSharp.Core), it was easy to match it, and there are some tests that the behaviour is the same, so that if there are any changes to the above in Option (which there is some ongoing discussion about, e.g. over null rendering), they are synced up with other DU non-reflection-based rendering.

It is obviously easy to make the changes to --reflectionfree mode a decisive improvement, since we are starting with nothing. However the intention would be that the behaviour is good enough to switch as a default in a future version of F#.

Note: this PR and #19971 add an identical v_string_operator_info and mkCallStringOperator.

[github-actions]

❗ Release notes required

You can open this PR in browser to add release notes: open in github.dev

---

✅ Found changes and release notes in following paths:

Change path	Release notes path	Description
src/Compiler	docs/release-notes/.FSharp.Compiler.Service/11.0.100.md

[kerams]

Kickass

[github-actions]

🔍 Tooling Safety Check — Affects-Compiler-Output
Affects-Compiler-Output: IlxGen.fs, prim-types.fs, Optimizer.fs modify IL emission and FSharp.Core runtime

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

[T-Gro]

Wouldn't' the newly added IlxGen feature codegen the same code that was now added by hand?

Thinking out loud:
Maybe this could be a separate feature (which would gent turned on automatically if you had --reflectionfree), but we could apply it even without it - either by project or by type.. ?

[charlesroddie]

Yes it would, if you turned on --reflectionfree, which would then break FSharp.Core since --reflectionfree bans "%A" usage. A separate feature would work for this purpose, at the cost of more plumbing.

The bigger question is when will consumers (both FSharp.Core and end users) who don't set --reflectionfree get the compiled ToStrings in the future. Turning on the flag by default would be dangerous because of the %A ban.

Perhaps the options are:

1. Introduce a new feature now, use it in FSharp.Core straight away, and in the future it could be on by default.
2. Stick with --reflectionfree, and in future make it on by default but remove the %A ban in it at that point (with %A possibly getting safer in future and with trim/AOT warnings available from the regular toolchain). Once this happens these explicit overrides can be removed from FSharp.Core.

[charlesroddie]

How about this @T-Gro :

• Make a LanguageFeature.CompiledToStrings
• FSharp.Core opts into this and then instead of adding manual ToStrings, this PR removes them from Option and ValueOption since they are now auto-generated.
• The implementation checks for either LanguageFeature.CompiledToStrings or --reflectionfree

[T-Gro]

I like that.

Just instead of a LanguageFeature, it shall be a dedicated compiler flag flowing via CompilerConfig.
LanguageFeatures go via a mapping from language version to sets of features, we cannot easily cherry pick one by one (unless this functionality is added).

CompilerConfig is better for dedicated flags that work orthogonal to versions of the language.

Can we still guarantee no breaking changes for regular , non reflectionfree , users of ToString() ?

[charlesroddie]

Happy to implement this. It's an extra flag that is hopefully temporary but presumably that's a small cost and it doesn't need to be publicized to end-users.

Used in FSharp.Core, the affected types will be:

• Option: this will have ToString removed and output will be unchanged.
• Result and Choice... types will go back to having no explicit ToStrings.
• Ref<'T> is affected and will need to be tested in the same way as Result but with record syntax.

Map and Set and List are unaffected since they have explicit ToStrings.

ValueOption has an explicit ToString but that should be removed since it's inconsistent: Some(0).ToString() gives "Some(0)" while ValueSome(0).ToString() gives "0" which should be corrected to "ValueSome(0)".

The behavioural changes for end-users will all be consistency improvements.

[charlesroddie]

OK good. Yes once done (in future work) the above FSharp.Core changes will make reflection-free codegen more useful, but it will also make anything that takes a string path more useful, including interpolated strings. E.g. currently $"{Ok 0}" does not give a useful result. So I'd classify it as a major bug at the moment, and I'll try to get a language suggestion out soon so we can start do deal with this.

[charlesroddie]

The FSharp.Core changes are reverted now.

[charlesroddie]

This thread resolved now @T-Gro ? Anything more to do in this PR?

[charlesroddie]

I created fsharp/fslang-suggestions#1468 which covers the points here.

[T-Gro]

@charlesroddie : I will post a few more things I found when testing this.

Will also suggest a comparison table to make the differences clear (and possibly use them to suggest followup work in future PRs) , and also something to be used when communicating the feature.

[T-Gro]

Anon records skip the recursion guard that nominal records/unions get. mkRecdToString here bypasses MakeBindingsForToStringAugmentation, where mightRecurse prepends EnsureSufficientExecutionStack().

// --reflectionfree
let mutable o : obj = box 0
for _ in 1..2_000_000 do o <- box {| Next = o |}
printfn "%s" (o.ToString())

Nominal { Next: obj } → catchable InsufficientExecutionStackException. Anon → hard Stack overflow., process abort (exit 134); the cycle is Operators.ToString ↔ AnonymousType.ToString(), no guarded nominal type in the loop. New crash vector vs. old reflectionfree (which emitted no anon ToString).

Suggestion: apply the same mightRecurse guard on this path.

[T-Gro]

DisplayName escapes special names with backticks; %A uses the raw name. Same at the union sites (lines 1759, 1773 ucase.DisplayName).

type U = ``My Case`` of int
// %A               :  My Case 5
// --reflectionfree :  ``My Case``(5)

Suggestion: use DisplayNameCore.

[T-Gro]

Baselines only cover a ref record + ref union. Add:

• a [<Struct>] record/union baseline (struct field-get path differs)
• an anonymous-record baseline (separate GenRecordToStringMethod codegen path — and the one missing the recursion guard, see IlxGen comment)

[T-Gro]

The --reflectionfree rendering diverges from %+A in enough ways to be worth documenting/announcing as acceptance wording. Not release-note material — suggest a durable docs/reflectionfree-printing.md this note can link to. Also currently omits anonymous records.

F#	%+A (default)	--reflectionfree
{ X = 1; Y = 2 }	{ X = 1⏎ Y = 2 }	{ X = 1; Y = 2 }
B 5	B 5	B(5)
C (3, "hi")	C (3, "hi")	C(3, hi)
Wrap "hi"	Wrap "hi"	Wrap(hi)
char field	'a'	a
{ P = None }	None	null
{ A = [|1;2;3|] }	[|1; 2; 3|]	System.Int32[]
{ V = ValueSome 2 }	ValueSome 2	2
U ()	U ()	U(null)
5.0	5.0	5
250uy / 42n / 1.5M	250uy / 42n / 1.5M	250 / 42 / 1.5
[<StructuredFormatDisplay("Custom<{X}>")>]	Custom<5>	{ X = 5 } (ignored)
``My Case`` 5	My Case 5	``My Case``(5) (see AugmentWithHashCompare comment)

[T-Gro]

It could go to https://learn.microsoft.com/en-us/dotnet/fsharp/language-reference/plaintext-formatting#a-formatting to communicate the differences.

I also want the table in this PR so that people can come in and express how acceptable the differences are (vs building on top of this PR and replicating reflection-based %A in codegen by switching over field type).

(pinging people who interacted with this PR: @kerams , @ShalokShalom , @smoothdeveloper , @jwosty )

[kerams]

Wrap(hi)

I think quotes should be preserved around strings so that there is no ambiguity without consulting the type's shape.

System.Int32[]

If we had something like tostring levels, then we could choose how complex the emission should be (should ToString generate code to iterate over a portion of any collection?). Then again, with --reflectionfree people supposedly care more about AOT than these strings, and one can always write a custom ToString, so maybe adding levels to this is needless complexity.