RFR: 8247283: Enable the new conformant preprocessor option in Visual Studio [v3]

[Magnus Ihse Bursie]

On Mon, 5 Sep 2022 12:55:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> The new conformant preprocessor has been feature complete since Visual Studio 2019.
>> 
>> We should start to use it instead of the traditional preprocessor (which is well known to be non-conforming in various ways). This would bring VS-based usage more in line with other platforms in this area, and remove the need for some workarounds for the traditional preprocessor's behavior. 
>> 
>> This PR is dependent on [JDK-8293162](https://bugs.openjdk.org/browse/JDK-8293162) "Drop support for VS2017" and [JDK-8293088](https://bugs.openjdk.org/browse/JDK-8293088) "Fix compilation with the new Visual Studio preprocessor".
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarify that Visual Studio 16.8 is needed

This was tricky to get right. One problem was that I misunderstood the Microsoft "marketing speak" about Visual Studio versions. This is how it works:

What Microsoft calls "Visual Studio 2019" is actually a whole family of versions. They also have an internal version number, which is `16.x`. The "minor" `.x` versions do still include significant new functionality, and changes command line options (so no semantic versioning here...).

When we introduced the `-std:c11` flag, I did test for "Visual Studio 2019", but what I really should have tested for was "Visual Studio 16.8". Similarly, for the new `-Zc:preprocessor` introduced in this PR, the minimum requirement is not "Visual Studio 2019", but "Visual Studio 16.5". Since I did not properly raise the bar to 16.8 when introducing `-std:c11`, I'm doing it now.

Secondly, the version scheme is messed up in many ways. To actually get to install "Visual Studio 16.8", you need to install a component called "MSVC 14.28" (of course 😵‍💫). And when you *have* installed it, the only way to make sure which version is installed is by querying the compiler, which will happily report version "19.28". :facepalm:

I have tried to make this more clear in the documentation.

Finally, for some reason I fail to understand, when installing "MSVC 14.28" in GHA, this still fails. I have no clue as to why. I can locally install 14.28 and it works. What goes wrong on GHA I can't even begin to guess, even less so debug it due to known (and well-disliked) reasons.

I did however find out that going one step further, to 14.29, solves the issue. This also has the added benefit of bringing both the aarch64 and the x64 windows environment on GHA to the same version.

-------------

PR: https://git.openjdk.org/jdk/pull/10101