Show default value of compiler options

[nih0n]

Description

Fixes #16294

I used the following files as reference to get the default values:

• CompilerConfig.fs
• DiagnosticOptions.fs
• CompilerOptions.fs
• fsc.fs

Unfortunately I could not make the Help - variant tests pass because of a generation mismatch on --delaysign and --realsig, I need a little bit of help on this

Checklist

• Test cases added

• Performance benchmarks added in case of performance changes

• Release notes entry updated:

  Please make sure to add an entry with short succinct description of the change as well as link to this pull request to the respective release notes file, if applicable.

  Release notes files:

  • If anything under src/Compiler has been changed, please make sure to make an entry in docs/release-notes/.FSharp.Compiler.Service/<version>.md, where <version> is usually "highest" one, e.g. 42.8.200
  • If language feature was added (i.e. LanguageFeatures.fsi was changed), please add it to docs/release-notes/.Language/preview.md
  • If a change to FSharp.Core was made, please make sure to edit docs/release-notes/.FSharp.Core/<version>.md where version is "highest" one, e.g. 8.0.200.

  Information about the release notes entries format can be found in the documentation.
  Example:

  • More inlines for Result module. (PR #16106)
  • Correctly handle assembly imports with public key token of 0 length. (Issue #16359, PR #16363)
    *while! (Language suggestion #1038, PR #14238)

  If you believe that release notes are not necessary for this PR, please add NO_RELEASE_NOTES label to the pull request.

[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.200.md

[T-Gro]

Thank you for the first contribution.

The default value for each switch can change over time (and it does), and is not only done so via .fs code in the compiler project itself, the default can also be specified in the respective Fsc and Fsi msbuild build tasks.

This makes a hardcoded selection of defaults, directly as text, prone to mismatches when settings are changed. Even more so when immediate changes of values can happen as a consequence of issues that need immediate fixing. This then resurfaces one more time as a result of tests needing a change every time a value changes it's defaultness as well.

The fact of settings being a "living" artefact that changes over time and the situation of being override-able at more levels (compiler project, Fsc/Fsi build task, xml config in .net sdk targets) makes a human-managed text easy to get wrong as time passes.

Another small, but acceptable, downside is that every text has to be localized for every supported language. And text needing review / retranslation, even if small suffix like "default:true" is added or when the default gets changed.

I think this only makes sense for acceptance if it can be fully automated and will not get in the way of changing values
(or risk being wrong).

[vzarytovskii]

+1 to what Tomáš wrote, hardcoding defaults for what they are at this point in time will bring more desynchronisation, ideally we want to generate them from the actual defaults in code (which might require a redoing how flags are parsed/stored).

[KevinRansom]

I think this is decent improvement to the command line compiler. It does make the things the compiler does a bit clearer.

It is fair to say that the way this feature is tested is a lot dependent on the console output and is thus sensitive to spelling corrections, additional options and text changes, but that is what the feature is.

As for translation, the repo is set up to make it as easy as possible for our translation partners to make those changes. So we would always take change that improve clarity.

[Martin521]

If the F# compiler is meant to be a product, then there must be documentation for the flag defaults. For both fsc and the build task. And every change of the default value must be documented and tested, also in "urgent" cases.
(At least for a set of "official" flags.)

Therefore, I like very much that this contribution makes an attempt to provide such documentation.
What is missing, in my view, is proper testing. (I.e. verification that what the help output says about the default is true.)

[vzarytovskii]

Therefore, I like very much that this contribution makes an attempt to provide such documentation.

Yes, however it's "hard-coded" here in the message itself, meaning when you change default for the given option, documentation won't reflect it, and one will need to go and change documentation, every single translation, change help baseline tests (and they won't be failing either if the default is changed accidentally).

Default values should be auto-generated from actual default values. But this will require change in how compiler options are organised. This will allow us to easier change defaults, and will prevent changing it accidentally, since baseline tests will start failing.

[nih0n]

Thanks for the feedbacks, @T-Gro is right this should be auto generated, I did this way because I saw --multiemit and --readline using hardcoded (on by default) and thought this was the way. I'm looking forward to improve this PR

[vzarytovskii]

Thanks for the feedbacks, @T-Gro is right this should be auto generated, I did this way because I saw --multiemit and --readline using hardcoded (on by default) and thought this was the way. I'm looking forward to improve this PR

That's a good point. I wander if should be hardcoding more or shall invest in having some universal mechanism of printing them.

[T-Gro]

We for sure cannot risk the defaults being wrong.

Between an automated test checking correctness, and an automated implementation - I am more inclined to an automated implementation.

[nih0n]

I've made some changes in the code and would like to know if I'm going in the right direction, my idea is to create multiple format*Option that will receive the option value and return a help text (e.g. "on", "off", "empty list of") to concat with the text from FSComp.txt. I'll mark this PR as Draft

[nih0n]

@T-Gro Now it's auto-generated, but I still have problems with compiler_help_output.bsl spacing.

[T-Gro]

@T-Gro Now it's auto-generated, but I still have problems with compiler_help_output.bsl spacing.

What is the spacing problem? Is it not deterministic?

[nih0n]

@T-Gro Now it's auto-generated, but I still have problems with compiler_help_output.bsl spacing.

What is the spacing problem? Is it not deterministic?

I pasted the expected and actual from the test output to an online diff and it shows that there's multiple spaces before the text I updated

I have no idea how to solve it, the compiler_help_output.bsl formatting looks correct to me.

[T-Gro]

I assume the help is printed using a maxWidth setting.
Can you copy the actual .bsl into the expected .bsl file? If it is an inline string in code right now, feel free to extract that into a separate file, if that makes working with whitespace and expectations easier.

[nih0n]

@T-Gro Fixed it, now I think it's ready for review

[T-Gro]

@T-Gro Fixed it, now I think it's ready for review

The test still fails on CI, was it passing locally?

Failed FSharp.Compiler.Service.Tests.ConsoleOnlyOptionsTests.fsc help text is displayed correctly [8 ms]
Error Message:
Assert.Equal() Failure: Strings differ
↓ (pos 702)
Expected: ···" name key\n--publicsign[+|-] "···
Actual: ···" name key (off by default)\n--p"···
↑ (pos 702)

[T-Gro]

The only failing tests are FsharpQA now - if you haven't seen it yet, the testguide https://github.com/dotnet/fsharp/blob/main/TESTGUIDE.md has instructions on it.

[nih0n]

The only failing tests are FsharpQA now - if you haven't seen it yet, the testguide https://github.com/dotnet/fsharp/blob/main/TESTGUIDE.md has instructions on it.

Passed

[vzarytovskii]

Great work, thanks a tonne!

[T-Gro]

This is ready to merge - it will auto-merge once release notes are added.
Can you please follow the very first comment in this PR? It shows instructions where and how to add release notes :).

[psfinaki]

Really good stuff, one of the things I was missing here - great work Fernando!