vs2019 update 16.10 : illegal initialization of `constinit` entity with a non-constant expression

[maxgolov]

What version of protobuf and what language are you using?

Version: 2021-04-07 version 3.15.8 Language: C++

What operating system (Linux, Windows, ...) and version?

Windows.

What runtime / compiler are you using (e.g., python version or gcc version)

Visual Studio 2019 msvc Update 19.10 . Latest version that just recently added support for constinit on May 25th - announcement here.

What did you do?

Nothing horribly bad.. Steps to reproduce the behavior:

1. Make sure the language set to C++20, -std:c++latest, e.g. for CMake that'd be set(CMAKE_CXX_STANDARD 20) .
2. Try to compile some code that uses generated protobufs that include port_def.inc header .

What did you expect to see

Code compiles.

What did you see instead?

Code fails to compile with errors:

Patch Proposal

The most trivial hacky patch would be to apply the same logic as applied for __GNUC__ , the issue described in #8310 .

Adding !defined(_MSC_VER) check - "resolves" the issue. And so constinit is not used:

// Our use of constinit does not yet work with GCC:
// https://github.com/protocolbuffers/protobuf/issues/8310
// Our use of constinit does not yet work with Visual Studio 2019 Update 16.10:
// https://github.com/protocolbuffers/protobuf/issues/TBD
#if defined(__cpp_constinit) && !defined(__GNUC__) && !defined(_MSC_VER)
#define PROTOBUF_CONSTINIT constinit

And the code works great after that even with latest Visual Studio 2019 compiler. This could be used as an interim patch to unblock customers using the latest compiler.

[netpoetica]

@maxgolov Thanks for posting this, I am seeing the same. Do you know which version of VSCommunity and Build Tools doesn't have this issue? On my local computer, I have VSCommunity 16.9.0 with

$ vcpkg list
grpc:x86-windows                                   1.33.1#2
protobuf:x64-windows                               3.14.0#1
protobuf:x86-windows                               3.14.0#1

and everything compiles fine, but I have a Docker image where I am using 16.9.0 from chocolatey

# Install Visual Studio, BuildTools, and compiler (CL.exe)
RUN choco install visualstudio2019buildtools --version=16.9.0 -y
# You need this one with you want CL.exe to exist
RUN choco install visualstudio2019-workload-universalbuildtools -y --package-parameters "--includeOptional" --confirm
RUN choco install visualstudio2019community --version=16.9.0 -y

with gRPC and Protobuf versions

grpc:x64-windows                                   1.37.0#2         An RPC library and framework
grpc[codegen]:x64-windows                                           Build code generator machinery
protobuf:x64-windows                               3.15.8#1         Protocol Buffers - Google's data interchange format

and I still see this error in my Docker build image, even with 16.9.0

[netpoetica]

FWIW I changed my CXX flags to use c++17 instead of c++latest and I was able to get around this issue w/ Protobuf and MSBuild (in case this helps anyone in the future) - only c++latest gives this problem. I also did not need to downgrade MSbuild/VSCommunity as long as I changed those CXX flags (in my case, in CMake triggering MSBuild).

[maxgolov]

@netpoetica - bug report repro steps indicate that: make sure the language set to C++20, -std:c++latest. You can avoid the issue by setting compiler flag to earlier language standard. For some projects it is impractical or impossible, esp. if projects actually need the new C++20 language features.

Since you are using vcpkg - you may workaround the issue by using vcpkg overlay to apply the patch. Take the contents from here: https://github.com/microsoft/vcpkg/pull/18251 , then point vcpkg to custom location of the patched package as follows: vcpkg install --overlay-ports=X:\path\to\patched\protobuf protobuf .. I have submitted the proposed patch to vcpkg, but unsure how long it'd take to merge.

[dlj-NaN]

This appears to have been resolved in VS2019 update 16.11.

On a side note: 16.11 was the first version to fully support C++20. In general, I would not expect std:c++latest to actually be stable or conformant, since it will often cover a not-yet-ratified standard (draft C++23 as of 16.11) with bugs of its own.

[jgcodes2020]

The issue seems to have unfixed itself at the moment: see #9698 and #10159