On 9/22/23 09:20, Stephan Bergmann wrote:
I just submitted
<https://git.libreoffice.org/core/+/1eef07805021b7ca26a1a8894809b6d995747ba1%5E%21>
"Bump baseline to C++20" to master. I will let it sit like that for a
few more days, to see if anything breaks (Coverity? Linux distros'
needs? etc.)
As
<https://git.libreoffice.org/core/+/5a40abc86b94c0be5b4a252c6ab5b0b0df6e520d%5E%21>
"Drop some newly obsolete __cplusplus version checks" revealed, "at
least for VS 2019 16.11.30 (but not for at least VS 2022 17.7.4), in
/clr mode (e.g., when compiling
cli_ure/source/climaker/climaker_app.cxx), the -std:c++20 is effectively
ignored, and compilation of such source files failed with
include\rtl/string.hxx(191): error C2955: 'rtl::OStringLiteral': use of class template requires template argument list
include\rtl/string.hxx(88): note: see declaration of 'rtl::OStringLiteral'
include\rtl/string.hxx(191): error C7592: a non-type template-parameter of type 'rtl::OStringLiteral' requires at least '/std:c++20'
include\rtl/string.hxx(397): error C2955: 'rtl::OStringLiteral': use of class template requires template argument list
include\rtl/string.hxx(88): note: see declaration of 'rtl::OStringLiteral'
etc. To work around that, keep the
<https://git.libreoffice.org/core/+/27d1f3ac016d77d3c907cebedca558308f366855%5E!/>
'O[U]String literals (unusable for now, C++20 only)' functionality
disabled when compiling /clr sources (i.e., where _MANAGED is defined)
for that old compiler."
I see three options here going forward:
(1) Pretend that there is no issue. Keep fingers crossed that "managed
C++" source files compiled with /clr do not include any files that
require a proper /std:c++20. Or add more kludges similar to the above
"To work around that, keep..." as needed. (For now, until we eventually
bump the MSVC baseline anyway, for whatever other reason.)
(2) Move compilation of such source files to not defining
LIBO_INTERNAL_ONLY (so that it is treated like 3rd-party code and
doesn't require C++11 or beyond at all). This would require checking
that those source files would already build fine with LIBO_INTERNAL_ONLY
undefined. I think instead of going down that rabbit hole of a hack it
would be better to
(3) Bump the MSVC baseline requirement from VS 2019 to VS 2022.
Thoughts, anyone?
