LO 24.2 C++20 baseline

[Stephan Bergmann]

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?