Note that the error only affects users trying to build Google.Protobuf directly using C# 11. It doesn't affect users who are compiling code against the pre-built library (which is likely to be basically everyone).
Fixes#11004.
(This is code I'm less familiar with than most of the library, and I'd be nervous of making any more wide-ranging changes. This seems pretty safe though.)
cc @JamesNK who first noticed this.
Closes#12261
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/12261 from jskeet:csharp-11 6bf22b892b
PiperOrigin-RevId: 518178901
This is already generated code, but wasn't included in our generation script. This change makes sure it will be up-to-date, and uses the now-conventional .pb.cs file extension.
This does *not* affect the conformance tests run from Bazel, as they generate the file separately and build the conformance tests using only Program.cs and the freshly-generated code. However, the csharp/src/Google.Protobuf.Conformance/BUILD.bazel still needs to be kept up-to-date with the filename change.
Closes#11880
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/11880 from jskeet:generate-conformance 34bb22cc46
PiperOrigin-RevId: 509542860
We will aim to get binary gems in 3.22.0, but if they aren't done we will do an all source release and bump to 4.22.0 at full release time.
PiperOrigin-RevId: 506075942
Descriptor was relying on the Root for the runtime check, but since the Root is
only startup up when needed, add the debug runtime check to the cases where the
Root isn't started up.
EnumDescriptors are normally started up by fields, but a developer could
directly call the public apis, so add the debug runtime check for safety sake.
PiperOrigin-RevId: 506062884
Looking back through history, figure out each place a generation change was
added and added compile asserts to help leave signals for what can be cleaned up
when if the legacy support is ever moved forward.
PiperOrigin-RevId: 506020387
(Edited by jskeet) For public release notes:
Add a public `IMessage.MergeFrom(ReadOnlySequence<byte>)` extension method, exposing existing internal functionality.
(Parsing a completely new message from `ReadOnlySequence<byte>` was already publicly available, just not merging.)
----
Public the `MergeFrom` method of type `ReadOnlySequence<byte>`.
We found that the `MergeFrom` method of type `ReadOnlySequence<byte>` is internal.
**We need it !!!**
Closes#11124
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/11124 from VAllens:patch-1 0ddea03042
PiperOrigin-RevId: 504575534
The ../ was causing an error in how the targets were being copied over. Since we have to copy the files anyway, it doesn't matter where we expect the files.
PiperOrigin-RevId: 503259682