Normal mode keeps the existing member function path.
In the future we might change this to a static member function instead to avoid the bloat of the member pointer, but that currently affects normal mode and we want to avoid it for now.
PiperOrigin-RevId: 672552340
The goal of the `names.h` convention is to have a single canonical place where a code generator can define the set of symbols it exports to other code generators, and a canonical place where the name mangling logic is implemented.
Each upb code generator now has its own `names.h` file defining the symbols that it owns & exports:
* `third_party/upb/upb_generator/c/names.h` (for `foo.upb.h` files)
* `third_party/upb/upb_generator/minitable/names.h` (for `foo.upb_minitable.h` files)
* `third_party/upb/upb_generator/reflection/names.h` (for `foo.upbdefs.h` files)
This is a significant improvement over the previous situation where the name mangling functions were co-mingled in `common.h`/`mangle.h`, or sprinkled throughout the generators, with no clear structure for which code generator owns which symbols.
With this structure in place, the visibility lists for the various `names.h` files provide a clear dependency graph for how different generators depend on each other. In general, we want to keep dependencies on the "C" code generator to a minimum, since it is the largest and most complicated of upb's generated APIs, and is also the most prone to symbol name clashes.
Note that upb's `names.h` headers are somewhat unusual, in that we do not want them to depend on C++'s reflection or upb's reflection. Most `names.h` headers in protobuf would use types like `proto2::Descriptor`, but we don't want upb to depend on C++ reflection, especially during its bootstrapping process. We also don't want to force users to build upb defs just to use these name mangling functions. So we use only plain string types like `absl::string_view` and `std::string`.
PiperOrigin-RevId: 672397247
This allows reusing some common string mapping functions in a lightweight library that does not depend on the rest of C++ protobuf.
PiperOrigin-RevId: 672079929
This change renames the helper functions to HasFieldSingular(), SetHasBit(),
ClearHasBit(), and SwapHasBit(), which should hopefully be less confusing.
First of all, the HasBit(), SetBit(), ClearBit(), and SwapBit() methods are all
private so they are easier to change than a public-facing API.
The function named HasBit is called for both proto2 and proto3 fields. For
proto2 fields, it returns true if and only if the hasbit is set -- i.e. if the
field is present. For proto3 fields, it returns true if and only if the field
is nonempty -- i.e. if the field is present.
See documentation here for what "field presence" means:
https://github.com/protocolbuffers/protobuf/blob/main/docs/field_presence.md
Note that in the proto3 case, what this function is doing has nothing to do
with bits!
The name HasFieldSingular is chosen to emphasize the fact that this function
has the same semantics has HasField, only that it's narrowly applied to
"singular" (i.e., non-repeating, non-oneof, non-weak) fields.
HasField itself is not a great name -- IsPresent is probably more appripriate
-- but it is a public API and therefore hard to change. This change at least
makes the two share a similar name.
(I considered `HasPresence` too but that also leaves room for ambiguity: "has
presence" might be interpreted to refer to whether a field is an explicit
presence field or an implicit presence field).
The other helper functions here do manipulate the hasbit directly. Because of
this, they should just make it obvious in the name.
PiperOrigin-RevId: 671966727
This works around a ReturnValueIgnored errorprone issue. There were several other places where this was already done, this is just catching up the remaining two places.
PiperOrigin-RevId: 671878499
<iostream> embeds a global constructor (to initialize std::cout and such), typically `static ios_base::Init __ioinit;` in libstdc++).
Replacing it by <istream>, <ostream> (or both) when possible has an impact on the number of global constructors involved (and thus on the number of instructions executed at startup).
Closes#18069
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/18069 from serge-sans-paille:feature/remove-useless-iostream 42d1458235
PiperOrigin-RevId: 671788440
This turned out to be much easier for upb than for C++. This CL pretty much
just does a cut-and-paste of the `ProxiedInMapValue` implementation from the
upb code generator to the runtime. This should help a bit with code size since
it removes the need to generate six `ProxiedInMapValue` implementations per
message.
PiperOrigin-RevId: 671438289
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
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
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
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
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
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
Protobuf Team Bot
Protobuf Team Bot
Joshua Haberman
Tony Liao
Cong Liu
serge-sans-paille
Evan Brown
Adam Cozzette
Thomas Van Lenten
Bo Anderson
Sven Mikael Persson
Mike Kruskal
tony