This is only used in some narrow edge cases, and is a less-safe version of our unknown field decoders. Switching to those reduces some duplication and improves error handling.
PiperOrigin-RevId: 704899254
The invariant is that PtrAndLen may hold ptr+len values which are legal for _either_ C++ string_view or Rust slices: constructing one from either Rust or C++ permits the laxest constraints, and care must be taken when converting a PtrAndLen into either type.
For "into Rust slice" case to handle is that len=0 ptr must be non-null, so len=0 ptr=null gets turned into an arbitrary non-null pointer as provided by std::ptr::NonNull::dangling() (any preexisting non-null ptr is kept in that direction).
For the "into C++ slice" the risk is more obscure that a Rust non-null pointer could potentially be an illegal pointer (such that ptr+0 is not a legal operation in C++), so when going into C++ we map any len=0 cases into ptr=null to avoid this as a possible risk.
PiperOrigin-RevId: 704776210
Lines with "//~ ..." should be considered a "first line" like non-"//~" lines, to avoid overly indenting when in raw strings.
PiperOrigin-RevId: 704689179
I found that `cargo test` fails without this, because even with `no_run`, Cargo
will still try to compile the code. It would be nice to have a working example
here, but unfortunately it's non-trivial to set that up since we would need a
real generated proto.
I also tweaked cargo_test.sh to run the doc tests so that we have CI coverage
for those.
PiperOrigin-RevId: 703611549
Migrate all tests to run on bazel 7 and fix errors that came up in the process. 30.x will no longer guarantee support for bazel 6.
#test-continuous
PiperOrigin-RevId: 703590770
Fixes protocolbuffers#10697: UnsafeDirectNioDecoder modifies shared buffer instance when performing aliased read.
I've included a test-ish reproducer in form of a unit test that fails fairly reliably, let me know whether you'd want this merged.
Closes#19405
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/19405 from mernst-github:mernst/aliasing 1d972091c3
PiperOrigin-RevId: 703588369
This is necessary for the generated code to work correctly even when it's
placed in a module instead of directly in the crate root. Now we can finally
delete the last of the gencode post-processing from the protobuf_gencode crate.
To get this to work properly I had to update the `Context` object to keep track
of the current module depth. This way we know how many `super::` prefixes we
need to prepend to an identifier to get back to the top level.
I had to some refactoring of our naming helper functions to get everything
working properly:
- Deleted `GetCrateRelativeQualifiedPath()`, since it seems simpler if we just
always provide unambiguous paths. I added some new `RsTypePath()` overloads
as a replacement.
- Made `RustModuleForContainingType()` a private implementation detail of
naming.cc, since the `RustModule()` functions are more user-friendly and
accomplish the same thing.
- Moved the logic for prepending super:: or the foreign crate name into
`RustModuleForContainingType()`. This way, all the helpers that call that
function automatically pick up the behavior we want.
PiperOrigin-RevId: 703555727
This required a tweak to the Bazel aspect to make it alias the appropriate
runtime (C++ or upb) under the name `protobuf`.
The nice thing about this is that it allows the same generated code to work
with both Bazel and Cargo. With Bazel the runtime crate is named `protobuf_cpp`
or `protobuf_upb`, whereas with the Cargo build it is just `protobuf`.
PiperOrigin-RevId: 703143472
This change updates the generated code to always prefix the names of crates
with `::` so that they can't conflict with local modules. I'm not aware of this
being an issue for anyone yet, but figured we might as well fix it proactively.
PiperOrigin-RevId: 703122266
Protobuf Team Bot
Mike Kruskal
Hong Shin
Protobuf Team Bot
Sandy Zhang
Adam Cozzette
Deanna Garcia
Eric Salo
Matthias Ernst