When we invoke protoc with `--include_source_info --descriptor_set_out`, we
currently strip out source-retention options but without doing the
corresponding stripping of the source code info. This CL fixes that problem by
making sure to strip the same entities from source code info that we stripped
from the main part of the descriptors.
PiperOrigin-RevId: 519831383
Fixes compile errors with GCC 13.
port.h:186:67: error: ‘uint32_t’ was not declared in this scope
port.h:187:67: error: ‘uint64_t’ was not declared in this scope
Closes#12331
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/12331 from jonaski:cstdint 9bef449478
PiperOrigin-RevId: 519208789
https://github.com/protocolbuffers/upb/issues/1220
There were two bugs here: Python was incorrectly mandating that a required
field be set during assignment, and it was also incorrectly assuming a non-NULL
return from an internal function call.
PiperOrigin-RevId: 518561818
- Replace uses of stack-based FixedArray instances with a heap-based stack.
This new stack amortizes memory allocations.
- Remove local variables of SpecificField. These are quite large and we only
use them temporarily to push into the vector. Better to push early and use the
value from the vector directly.
PiperOrigin-RevId: 518320703
Update the Partially proto matcher to cause proto parsing to check fail if the above condition was triggered.
This is to address a known issue where test are silently passing when proto3 protos are the arguments to Partially(EqualsProto) and have some of the fields ignored by the EqualsProto matcher since they were set to their default value in the expected proto.
PiperOrigin-RevId: 518262030
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
PHP 8.2 is around the corner, and they've just published 8.2.0RC2.
So, what about testing protobuf with it?
Also: even if everything compiles and the PHP extension can be used, we may have that PHP throws some warnings at startup.
For example, if we install protobuf 3.18.3 with PHP 8.1, we have these warnings:
```
$ php -r 'echo "This is just a test.\n";'
Deprecated: Return type of Google\Protobuf\Internal\RepeatedField::offsetExists($index) should either be compatible with ArrayAccess::offsetExists(mixed $offset): bool, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in Unknown on line 0
[...omissis... ]
Deprecated: Return type of Google\Protobuf\Internal\MapFieldIter::rewind() should either be compatible with Iterator::rewind(): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in Unknown on line 0
This is just a test.
```
So: what about letting the `php-ext.yml` GitHub Action fail in case we have such startup errors?
Closes#10596
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/10596 from mlocati:php-8.2-warnings 6383242b14
PiperOrigin-RevId: 518050302
This will be used to make the method and enum to package-private and later to visibility-restrict other deprecated APIs for editions to prevent backslide.
PiperOrigin-RevId: 518028723