Protobuf PHP Extension
When building the module under Linux, the config.m4 file compiles the module files "arena.c array.c convert.c def.c map.c message.c names.c php-upb.c protobuf.c" and in addition it compiles the third party file "third_party/utf8_range/utf8_range.c"
When building under Windows, a separate config.w32 file is used which compiles the same "arena.c array.c convert.c def.c map.c message.c names.c php-upb.c protobuf.c" module files, but in addition, it compiles *.c from the third_party/utf8_range subfolder. Some of these files are not compatible with windows due to including <sys/time.h>. Only the utf8_range.c file is required, as shown under the config.m4 linux build configuration.
This PR modifies the build script config.w32 so that builds under windows only compile the same files that is compiled under linux. It removes the wildcard compile of the entire third party include, and thus resolves the build error under Windows.
Here is the linux build config.m4 file for reference. 72707c38f3/php/ext/google/protobuf/config.m4 (L1-L11)
Verified working under :
Microsoft Windows 11 Pro 24H2 x64
Micrsoft Visual Studio Community 2022 (17.0 - 14.41.34120) x64 Build Environment
Builds against PHP 8.3.10 from source in full PHP recompile
Closes#17903
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/17903 from gwharton:main ebfc0e3b52
PiperOrigin-RevId: 700529908
Otherwise libprotoc built by CMake hides symbols needed by grpc-java (https://github.com/grpc/grpc-java/issues/11475)
---
I wasn't sure if other functions should be exposed, but just added them based on objectivec/names.h where everything is PROTOC_EXPORT.
Can restrict to only minimum if preferred (for grpc-java, this would be `ClassName`)
Closes#19363
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/19363 from cho-m:java-names-protoc-export 1bf84d4368
PiperOrigin-RevId: 700381234
.NET 8 added support for `AddRange` using the `ReadOnlySpan<T>` data structure. This can significantly improve the performance of `RepeatedField<T>` when adding multiple elements and can avoid the potential need to create extra arrays when using spans.
Here is the code that was added to .NET to support `AddRange` on `List<T>`: 85f6d2d944/src/libraries/System.Private.CoreLib/src/System/Collections/Generic/CollectionExtensions.cs (L85-L103)
In the current implementation of `RepeatedField<T>`, the `AddRange` method only operates on `IEnumerable<T>`. Unfortunately, this means that the callers using `Span<T>` have to copy the content of the span to an array or to some other `IEnumerbale<T>` before calling `AddRange`. This is an expensive operation and can be avoided by adding support for `AddRange` that takes a `ReadOnlySpan<T>` directly.
In this proposal, `AddRange` is added as an extension method instead of directly adding it to `RepeatedField<T>` because we want to avoid ambiguity between `RepeatedField<T>.AddRange(IEnumerbale<T>)` and `RepeatedField<T>.AddRange(Span<T>)` for types such as `T[]`. This is the same exact approach taken by .NET runtime itself.
Closes#19115
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/19115 from prezaei:pedramr/repeated-field-extensions 8d0ac6a0c3
PiperOrigin-RevId: 700357702
Comparing against empty string will first do a reference comparison, then value comparison.
Whitespace changes are caused by `trim_trailing_whitespace = true` in `.editorconfig`
Closes#18934
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/18934 from Henr1k80:main 7467044f8e
PiperOrigin-RevId: 700355679
Used the python rules as an example to fix this. Bazel now recognizes that the output files have been produced, where before there were build failures regarding the outputs not being produced.
Closes#18255
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/18255 from tempoz:tempoz-fix-rust-outputs dfad229785
PiperOrigin-RevId: 700285611
The test wrappers were another way to document nonconformant behaviour between
different python backends. We can achieve the same by removing the wrapper
script and adding an if-condition in the test itself based on
api_implementation.Type(). Since we already do that for nonconformance between
pure Python vs. C++ backends, this change makes it easier to look for UPB
nonconformance instead of going through another layer of indirection.
PiperOrigin-RevId: 700127942
We previously hit this for NAN, but it appears the latest version of MSVC used in windows github runners has the same issue for INFINITY. The same strategy can be applied here.
This will be backported to fix broken release branches.
PiperOrigin-RevId: 700042372
The test wrappers were another way to document nonconformant behaviour between
different python backends. We can achieve the same by removing the wrapper
script and adding an if-condition in the test itself based on
api_implementation.Type(). Since we already do that for nonconformance between
pure Python vs. C++ backends, this change makes it easier to look for UPB
nonconformance instead of going through another layer of indirection.
PiperOrigin-RevId: 699321395
After using UPB I noticed that field accessors were not getting inlined properly using Clang. The source appears to be the UPB_FORCEINLINE macro falling back to just being `static` when underneath clang despite clang having full support of the required attributes.
Closes#17433
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/17433 from Vadmeme:main 57204e78cd
PiperOrigin-RevId: 699195477
Before we were trying to work around the fact that we don't know the default depth limit. The logic is simpler and more robust if we take the default into account.
PiperOrigin-RevId: 698856552
Unversioned libraries / libraries without due ABI indicators are not allowed in certain Linux distributions because it precludes the concurrent presence of multiple versions.
If you have both /usr/lib/libprotobuf-lite.so.28.3.0 and /usr/lib/libprotobuf-lite.so.29.0.0, both of them want libutf8_validity.so, but if the ABI is different between utf8_range 28 and utf8_range 29, that's a problem.
Closes#19009
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/19009 from jengelh:master 1a5f8682be
PiperOrigin-RevId: 698855702
The data is not currently used. This change is what we need to hook it up from Rust. In a future change we will start using the data to simplify the interface.
No expected performance change. The data inserted via static typing is constant evaluated, and fits in the existing padding (in 64-bit builds).
Also, fix Rust bindings to take float/double into account now that the enum lists them.
PiperOrigin-RevId: 698780360
[bug] tutorialpb/addressbook.pb.go:317:40: predeclared any requires go1.18 or later (-lang was set to go1.14; check go.mod)
Closes#19293
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/19293 from Kaikaikaifang:patch-2 386a337031
PiperOrigin-RevId: 698606584
Protobuf Team Bot
Protobuf Team Bot
Mike Kruskal
Taylor Cramer
Vitaly Goldshteyn
Graham Wharton
Sandy Zhang
freeform-andre
Zoey Greer
Michael Cho
Dennis
Pedram Rezaei
Henrik
Antonin Kriz
Tony Liao
Anton Grbin
Jie Luo
gongsu832
Chris Kennelly
Vadmeme
Joshua Haberman
Jan Engelhardt
Kaikai