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

@nih0n,

Caution

No release notes found for the changed paths (see table below).

Please make sure to add an entry with an informative description of the change as well as link to this pull request, issue and language suggestion if applicable. Release notes for this repository are based on Keep A Changelog format.

The following format is recommended for this repository:

* <Informative description>. ([PR #XXXXX](https://github.com/dotnet/fsharp/pull/XXXXX))

See examples in the files, listed in the table below or in th full documentation at https://fsharp.github.io/fsharp-compiler-docs/release-notes/About.html.

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

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

Change path	Release notes path	Description
src/Compiler	docs/release-notes/.FSharp.Compiler.Service/9.0.200.md	No release notes found or release notes format is not correct

[T-Gro]

The default is an empty delimited list.
Plus means to report warnings as errors.
Minus should mean to exclude from the global (just above) warn as error feature.

[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