On 10/22/2018 4:32 AM, Niall Douglas via Boost wrote:

On 21/10/2018 05:44, Edward Diener via Boost wrote:

...

If anyone wants to try this out on Boost PP 'develop' feel free to do so. You will need to invoke the msvc-14.1 toolset in Boost Build with the /experimental:preprocessor switch and you will need to upgrade VS2017 to 15.8 or above. You can tell whether you have succeeded invoking the Boost PP tests with the new preprocessor by looking at the run output of the config_info test. If the BOOST_PP_CONFIG_FLAGS() is 0x0001 it is the new preprocessor, else it is the default non-standard preprocessor (0x0004).

What's your general opinion of the quality of the new MSVC preprocessor?

It needs to be bug free when run against the Boost PP and Boost VMD tests, else it is not standard conforming as far as I can know. I have not tried it against the Boost VMD tests yet but I will. The fact that there are still some bugs when run against Boost PP means it still needs to be fixed further. Of course I am not claiming that Boost PP or Boost VMD tests actually test every possible situation in a C++ standard preprocessor, but they are pretty good in testing a great many of its macro expansion situations. Microsoft did triage my bug report about the wrong number of arguments to a macro giving a warning rather than a compiler error so that is encouraging. It would be real nice if Microsoft provided a means, as part of the new MSVC preprocessor, to show their own step-by-step output of any given macro's expansion as this would make it much easier to find and report the bugs in a much more simple example which are still occurring in the Boost PP testing. I can of course use Boost Wave, which is a great tool, but that shows how a given macro should expand according to the C++ standard and not how MSVC macro expansion is actually happening. OTOH, as part of a bug report, I can just point Microsoft to the Boost PP tests which are failing or producing incorrect warnings, but I doubt that is acceptable as a bug report on which they will act. Of course it is encouraging that after so many years of supporting a non-standard C++ preprocessor Microsoft is finally attempting to create a standard C++ preprocessor.

Niall

On 10/22/2018 6:03 AM, Peter Dimov via Boost wrote:

Edward Diener wrote:

...

OTOH, as part of a bug report, I can just point Microsoft to the Boost PP tests which are failing or producing incorrect warnings, but I doubt that is acceptable as a bug report on which they will act.

I think that it is. Boost is part of their in-house test suite.

The update to use the new preprocessor is currently only in the Boost PP 'develop' branch, although I will merge to 'master' before 1.69 closes. Is testing directly from Boost source part of their in-house test suite ? Probably STL knows but I do not.

On 10/22/2018 5:11 PM, Peter Dimov via Boost wrote:

Edward Diener wrote:

...

The update to use the new preprocessor is currently only in the Boost PP 'develop' branch, although I will merge to 'master' before 1.69 closes. Is testing directly from Boost source part of their in-house test suite?

I think that they use a release. They're probably on 1.68 now, don't know their policy on upgrading it. I could be wrong though.

In that case telling them to run the tests on the 'develop' branch of Boost PP passing /experimental:preprocessor to the b2 command line, in order to verify a particular failure occurring from the result, is probably not going to be acceptable as a bug report. But I will try it.

OTOH, as part of a bug report, I can just point Microsoft to the Boost PP tests which are failing or producing incorrect warnings, but I doubt that is acceptable as a bug report on which they will act.

Outcome has been part of MSVC's test suite for some months now, as is Boost. Outcome has broken MSVC in all sorts of subtle and interesting corner case ways. Microsoft have spotted the failure within 24 hours, triaged it, and self fixed the problem, usually providing an ETA of when the compiler fix will ship. So Edward if I were you, I'd make Boost.Preprocessor and Boost.VMD for the 1.69 release use standard preprocessor if you detect it is enabled in MSVC. That'll cause MSVC to fail in the Boost conformance testing. That in turn will ensure Microsoft triage and fix all outstanding problems in super quick time. That's my recommendation to you, anyway. Niall

On Mon, Oct 22, 2018 at 8:54 PM, Niall Douglas via Boost wrote:

...

OTOH, as part of a bug report, I can just point Microsoft to the Boost PP tests which are failing or producing incorrect warnings, but I doubt that is acceptable as a bug report on which they will act.

Outcome has been part of MSVC's test suite for some months now, as is Boost.

Outcome has broken MSVC in all sorts of subtle and interesting corner case ways. Microsoft have spotted the failure within 24 hours, triaged

Within 24h of what? Release? If so, how come they didn't spot and fix it before release? -- Olaf

On Mon, 22 Oct 2018 at 20:54, Niall Douglas via Boost wrote:

That'll cause MSVC to fail in the Boost conformance testing. That in turn will ensure Microsoft triage and fix all outstanding problems in super quick time.

That's my recommendation to you, anyway.

+1 degski -- *“If something cannot go on forever, it will stop" - Herbert Stein*