This past reliance doesn't work well with Swift, and the sources
were trying to over hand optimize to minimize rebuilds, and that
likely isn't worth the trouble, so explicit imports.
The remaining places that still use them are where they are
needed within the header to deal with relationships between
the local definitions or where there is a cycle between the
headers and it allows either one to be imported first and still
get a complete definition in the using context.
PiperOrigin-RevId: 671379912
This version works where both sides are the same message, messageview or messagemut type, but not any mix of them (e.g. cannot compare a message against its corresponding view).
PiperOrigin-RevId: 671091099
This also increases compliance by adding `default_applicable_licenses` to several `BUILD` files that previously did not have it.
PiperOrigin-RevId: 670784686
This avoids some extra copies and garbage generation.
There's still the extra default 10-sized backing array created by default in
ProtobufArrayList which isn't fixed yet, which we see in allocation tests. That's from `ensureXIsMutable()` which allocates a new list without awareness of the list's size. Maybe we can fix that later: b/362848901.
PiperOrigin-RevId: 670766317
I've tried to keep the hot part of the loop (not null) in the loop without
requiring an extra function call, and only extracted the cold part (null
handling) to avoid repetition.
PiperOrigin-RevId: 670760103
The way AnyMetadata works is by holding two pointers to the fields of
google.protobuf.Any, and its methods `PackFrom` and `UnpackTo` mutates these
pointers directly.
This works but is a bit overcomplicated. A whole new object is created to
mutate members of Any directly, breaking isolation. Each Any object will also
need to unnecessarily create room to hold an AnyMetadata object, which is at
minimum the size of two pointers.
By removing AnyMetadata and using free functions, the call site passes
`const Value& foo()` and `Value* mutable_foo()` directly into `PackFrom` and
`UnpackTo`. This is more idiomatic and will play well with hasbits.
The only catch here is that in some templated implementations of `PackFrom` and
`UnpackTo`, caller will need access to T::FullMessageName(), which is in
private scope. The workaround here is to have a single templated helper
function that is made into a friend of google.protobuf.Any, so that it has the
right visibility.
PiperOrigin-RevId: 670722407
These are very old unit-tests that appear to have been written to provide some conformance capabilities before we had more comprehensive solutions. Today, they should be already covered by our conformance tests and create unnecessary noise.
The goal of this change is to simply desynchronize the Java and C++ text format golden files. Java at least seems to be using these for a dual-purpose for both locking down conformance and unit-testing text format behaviors.
PiperOrigin-RevId: 670596733
When the user adds `option deprecated = true` for an `enum` or `message`, we
should add the `[[deprecated]]` attribute to the generated C++ `enum` or
`class`.
PiperOrigin-RevId: 670583253
The old generated code suppressed warnings broadly to support protobuf
deprecations like this showing to users, but the previous commit does
provide a debug log statement for the usages.
PiperOrigin-RevId: 670581568
We need this type to be trivial and standard layout because we directly read
its contents in Rust. This change removes its user-defined constructors so that
it becomes a trivial type.
PiperOrigin-RevId: 670572557
The symbol renaming support has assumed folks would define a
custom version of the macro, but if a developer does renaming
just by #defining the class, the extension singleton names
required manual handing, by changing to just wrap the class
in the macro and using the compiler string concat support
it becomes easier as just the class name remapping can do
the work for extensions.
PiperOrigin-RevId: 670536928
On macOS 15, the test suite was crashing due to `pipe()` failing with `EMFILE`. On inspecting `lsof`, it appears the file descriptor table was full of duplicated `tty` file descriptors.
I'm not entirely sure what's changed in macOS 15 to tip it over the limit, but there was nevertheless clearly a file descriptor leak and this PR fixes that.
We were calling `dup(1)` and `dup(2)` to copy stdout/stderr to new temporary file descriptors, storing it `original_stdout_` and `original_stderr_`, later moving it back to FD 1 and 2 but never actually closing the temporary file descriptor.
Closes#18021
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/18021 from Bo98:fd-leak 3df847287e
PiperOrigin-RevId: 669528160
This CL is mostly a no-op, except that now google3-only code is actually stripped from OSS, instead of being preserved in `# begin:google_only` blocks.
This follows the conventions of the greater Copybara ecosystem.
PiperOrigin-RevId: 669513564
This simplifies upb by removing differences between google3 and OSS.
This also points upb at the protobuf license, instead of keeping a separate copy around for upb.
PiperOrigin-RevId: 669447145
This unfortunately makes the file significantly less compact. But given that Cider will automatically perform this formatting whenever you save, this seems like a fight we are not going to win.
PiperOrigin-RevId: 669430466
Fixed some shadowing between local variables
Pretty simple fix, just renaming a couple local variables so they don't shadow other variables in scope. Just trying to reduce verbosity of warnings in users' own builds with higher warning levels (as is my case ;) ).
Obviously, no change in behavior, and hopefully the new names are reasonable.
Closes#17971
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/17971 from mikael-s-persson:fix/shadowing_vars ad454e7a2a
PiperOrigin-RevId: 669393734
For some reason, Clang 19 appears to raise an error in some situations unless
we explicitly inline the implementation of `StrongPointer()` here.
PiperOrigin-RevId: 669373421
This relates to:
Issues:
- https://github.com/protocolbuffers/protobuf/issues/17036
- https://github.com/grpc/grpc/issues/36518
PRs:
- https://github.com/protocolbuffers/protobuf/pull/15519
The fix in https://github.com/protocolbuffers/protobuf/pull/15519 has one line missing that breaks `Grpc.Tools` and doesn't actually fix the problem it proports to fix.
This PR fixes this.
This fix needs to also be applied to the version of protobuf that is used by gRPC.
There are various scenarios that need to be tested on Windows:
**A. Non-ascii command line arguments, e.g.**
```
protoc.exe --csharp_out=out --proto_path=E:\work\grpc\protoctest\test-Dré E:\work\grpc\protoctest\test-Dré\helloworld.proto
```
Failed output:
```
E:\work\grpc\protoctest\test-DrΘ: warning: directory does not exist.
Could not make proto path relative: E:\work\grpc\protoctest\test-DrΘ\helloworld.proto: No such file or directory
```
Success output:
- no errors printed
- generated `.cs` file in the `out` directory
**B. Non-ascii arguments in a file containing the protoc arguments (no path to file) e.g.:**
```
protoc.exe @test.rsp
```
where `test.rsp` contains:
```
--plugin=protoc-gen-grpc=E:\work\grpc\protoctest\tools\grpc_csharp_plugin.exe
--csharp_out=E:\work\grpc\protoctest\test-Dré\out
--grpc_out=E:\work\grpc\protoctest\test-Dré\out
--proto_path=E:\work\grpc\protoctest\test-Dré
helloworld.proto
```
Success output for both old and fixed code:
- no errors printed
- generated `.cs` file in the `out` directory
**C. Non-ascii arguments in a file containing the protoc arguments (with non-ascii path to file).**
(This is what `Grpc.Tools` uses.) e.g.
```
protoc.exe @E:\work\grpc\protoctest\test-Dré\test.rsp
```
Failed output:
```
Failed to open argument file: E:\work\grpc\protoctest\test-DrΘ\test.rsp
```
Success output:
- no errors printed
- generated `.cs` file in the `out` directory
Closes#17854
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/17854 from tonydnewell:windows-utf8-command-fix de9ec5401e
PiperOrigin-RevId: 669083804
This test case attempts to pack an Any with a message over 2 GiB in size, but
the allocation is failing in our 32-bit Windows test. This change should fix
the problem by skipping the test case on 32-bit platforms.
PiperOrigin-RevId: 669082000
Now 'thunk' is only for cpp kernel we don't need lots of special casing to replicate the upb accessor names (we basically have free choice of name instead).
Since the ThunkName() function should only be used from cpp kernel, it now check-fails if its called from upb kernel, which requires pushing down the thunkname() calls to the cpp-kernel specific paths in some cases.
PiperOrigin-RevId: 668958849
Thomas Van Lenten
Protobuf Team Bot
Derek Benson
Protobuf Team Bot
Joshua Haberman
Mike Kruskal
Hong Shin
Mark Hansen
Tony Liao
Evan Brown
y-yagi
Adam Cozzette
Hood Chatham
Bo Anderson
Sven Mikael Persson
tony