This is not strictly necessary, but I think it will be convenient to have a
single Bazel target that represents all the crates we want to publish with each
release.
PiperOrigin-RevId: 732219832
Use the `substitute_rust_release_version()` macro instead of a one-off genrule.
Also update lib.rs to reflect that we now generate a `generated.rs` file that
exports code for all the .proto files, instead of having a primary `pb.rs`
file.
PiperOrigin-RevId: 730882117
These files were previously set up as templates so that we could inject the
version number during the build before pushing crates to crates.io. However, having
the README files be readable in their checked-in form is nice, and we can
auto-update the version numbers in place.
PiperOrigin-RevId: 729242250
Before this change, the way it works is that we emit one .rs file per input .proto file, and a multi-src proto_library are handled by considering the first file as specially the 'primary' one which specially re-exports everything defined in other files.
After this change, we instead emit the .rs file per .proto file equally, and then we additionally emit a generated.rs file which re-exports all of them.
PiperOrigin-RevId: 707569226
For now the error message describes how to build protoc and
protoc-gen-upb_minitable from source using CMake. Hopefully this will be
temporary, since we should be able to point to prebuilt binaries for both once
we have a real release out.
PiperOrigin-RevId: 707147611
It's not yet possible to import any of the well-known types from a proto file
in another crate. To enable this I think we'll need to generate a function that
dependent crates can call to determine the directory that contains the
well-known types.
PiperOrigin-RevId: 706745114
Proto file paths generally need to be globally unique, or at least unique
within the same binary. A file conflict might be tolerated in protobuf
implementations without reflection, but ones that do support reflection will
have trouble building a descriptor pool that has one more than one proto file
with the same path.
This change therefore updates the example crate to put the proto files inside a
`proto_example/` directory since this lessens the chance of a conflict. Not
that we really care about the example crate conflicting with anything, but I
think this makes it a better example to follow.
PiperOrigin-RevId: 705982825
I also added a check to ensure that `protoc --version` matches the protobuf
runtime version. The minitable generator plugin version should also match, but
unfortunately we can't easily check this today because it does not provide a
way to check its version.
PiperOrigin-RevId: 705944904
Also update the protobuf_example crate to use the OUT_DIR instead of the source in the /src dir.
This will avoids problems of the outdir having stale files that shouldn't be there anymore still being picked up in the build.
PiperOrigin-RevId: 705609005
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
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
Starting from the 2018 edition of Rust, paths starting with `::` must refer to
a crate, so when we refer to `::std` there is no risk of accidental collision
with another identifier.
Using `::std` instead of `::__std` is useful because it works even when the
generated code is in a module rather than directly in the crate root. This
allows us to remove one of the post-processing steps from the codegen crate.
PiperOrigin-RevId: 702858213
Temporarily rename the crates `staging-` while we're iterating on this.
This works for the protobuf and protobuf_codegen crates, but the protobuf_example crate fails to publish as cargo does not want build.rs to affect files outside of the OUT_DIR.
PiperOrigin-RevId: 702840478
Add trivial README.md files for this to pass.
This will catch some but not all issues with the crates that would cause them to be rejected by crates.io
PiperOrigin-RevId: 702766719
The Cargo.toml sets both path and version for its dependencies: the mechanism is that path is used if possible (which it is for our test script), but is automatically stripped from the .toml file when uploadeded to Crates.io
PiperOrigin-RevId: 702721439
Adam Cozzette
Protobuf Team Bot