In CMake >= 3.0 it is more idiomatic to set per-target compiler options than global compiler settings. I have kept these options and defines as `PRIVATE` so they won't be exported with the target.
Closes#12916
In jruby `runtime.evalScriptlet('Encoding::UTF_8')` can be broken under a newly created thread, which can cause protobuf encoding to fail. For example: https://github.com/ntkme/sass-embedded-host-ruby/actions/runs/5108602231/jobs/9182569583#step:5:544
It real issue seems to be in jruby itself. A bug report with minimal reproduction has been filed at https://github.com/jruby/jruby/issues/7820
This PR fixes the problem by effectively replacing `runtime.evalScriptlet('Encoding::UTF_8')` with `runtime.getEncodingService().convertEncodingToRubyEncoding(org.jcodings.specific.UTF8Encoding.INSTANCE)`, which works on all threads.
Closes#12919
This updates kMapWithProto2EnumValue -> kLegacyEnumIsClosedBit s.t. this bit now indicates closedness for enum fields as well, not just maps with enum values.
PiperOrigin-RevId: 535782238
This is a macro on some (older) versions of GCC, and macOS, and Windows. Sigh. I moved the `#undef` block to a common section. I also took the opportunity to add a regression test for all these macros that need to be `#undef`'d.
Part of the work for googleapis/google-cloud-cpp#8125
Closes#12903
This will require C++14 (or higher) for the `libproto*` targets **and** anything that links them. If multiple dependencies have different C++ requirements, CMake will use the maximum version. It does not work with pkg-config, and does not work if the downstream dependency forcibly downgrades the compiler to C++11 (or lower). But prevents many problems. Note that if Abseil was compiled with C++17 it will require C++17 and that will propagate through Protobuf.
Closes#12901
Marcel Hlopko
Protobuf Team Bot
Protobuf Team Bot
Carlos O'Ryan
なつき
Jie Luo
Mike Kruskal
Sandy Zhang
Adam Cozzette