Design the /warnversion command-line interface and compiler API

[gafter]

What are the set of values accepted on the /warnversion compiler command-line flag?

Does it affect/change the /warn setting? Should they be the same (existing) flag?

How can the user discover the set of legal values? How can the user discover the set of warnings enabled by a given version?

[gafter]

/cc @jcouv @333fred @cston @jmarolf

[gafter]

See also #45906

[CyrusNajmabadi]

Note: i liked fred's point about this being a diagnosticwave rather than a warningwave. so maybe it's diagnosticversion. and later diagnosticversions can bring in new diagnostics (which might be warnings or errors). You can then independently change warnings to errors as you see fit.

[agocke]

Copying over my previous vociferous objection to representing version numbers using number types:

Version numbers are not numbers. Thinking of a version number, like 5.1, as a number is a failure of pattern matching. Using a decimal allows you to specify versions that don't exist, like 3.1415926535, and does not let you specify versions that may exist, like 5.1.1.

LangVersion uses an enum, because the correct way to model versions is that the actual supported versions is a closed enumerated set. The actual version number passed on the command line is a string, and could only be accurately represented by a string. Version numbers should be parsed like any other option, then processed into a type-safe format (enum).

[gafter]

We have dropped the proposed /warnversion flag. We are simply adding new values to the existing /warn flag. The first "new" value will be "5" in C# 9. However, the /warn flag permits passing higher values now if you want to accept future warning "waves".