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
This being unused in some cases is causing a warning at head, just suppressing the warning rather than conditionally emitting it only when we need it.
PiperOrigin-RevId: 668937899
The extern "C" block in messages is now:
- Cpp kernel: All of the message/accessor/oneof externs
- Upb kernel: Only the upb_MiniTable extern
PiperOrigin-RevId: 668518308
instantiate objects if permitted by the compiler.
We can use memset for zero initialized objects, and memcpy for ones cloned from
the prototype.
This permits creating objects from the parser without calling virtual
functions.
For the cases where the efficient implementation can't be used, we generate a
"placement new" style function to offload the memory allocation out of the code
generation. This reduces code bloat even when we can't use the more efficient
implementation.
Migrate many callers of `New` and similar to the new functionality. In
particular, the parsing paths will use this.
Finally, make `New` non-virtual now that `MessageLite` can handle it directly.
It reduces binary size.
PiperOrigin-RevId: 668077355
`unsafe trait` means that the _implementation_ has constraints they need to meet for the behavior to be safe (which is the intent here, namely that it should always return the same value and always be a safe to deref value), unsafe on the fn means that the _caller_ of that fn has some constraints they need to meet for it to be safe (of which there are none in this case).
PiperOrigin-RevId: 668028628
Migrate some internals of the library off the older apis.
Also mark some of the old apis as deprecated, but the old generated code
suppressed warnings broadly to support protobuf deprecations.
PiperOrigin-RevId: 668003974
This just behaves the same as the pre-existing upb_Message_SetMessage(), but with the intendended naming style (upb_Message_SetMessage should accept an arena and support extensions).
PiperOrigin-RevId: 667998428
This unifies the duplicated logic that we had for each different non-repeated field to emit these same 3 methods for each of the different field types, and moves the has/clear off of upb-accessors-C-codegen and onto the upb-C-API for all cases (matching the singular scalars case which moved in a previous change).
PiperOrigin-RevId: 667953223
These types are effectively two ways to spell the same type, but MapView/MapMut is more terse, especially where the unnamed lifetime was used which can now be implied (`View<'_, Map<K, V>>` can just be `MapView<K,V>`)
PiperOrigin-RevId: 667636945
Adam Cozzette
Protobuf Team Bot
Protobuf Team Bot
Mike Kruskal
tony
Hong Shin
Jie Luo
Thomas Van Lenten
Evan Brown