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
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
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
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
Adam Cozzette
Protobuf Team Bot