This uses https://github.com/protocolbuffers/rules_ruby to fully Bazelify our ruby runtime code. The Rakefile is left in place for now and is still used by our aarch64 tests. With the current implementation ruby behaves similarly to our python wrapper, which selects whatever version is installed in the system. Future enhancements will allow for more hermetic builds via Bazel flags to pin a specific version
Closes#10525
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/10525 from mkruskal-google:rules_ruby 97fa1f70ab
PiperOrigin-RevId: 499283908
I updated our Bazel CI jobs to cover `//pkg/...` and thereby exercise this new
test. That made me realize that `//pkg/...` was not fully buildable because
there was a reference to the non-existent target `@utf8_range//:dist_files`, so
I also fixed that.
PiperOrigin-RevId: 498437497
We would like for upb_Map_Delete() to optionally return the deleted value.
Unfortunately this will require several steps since we are crossing repos.
Step #4: advance the upb version used by protobuf and update PHP/Ruby accordingly.
PiperOrigin-RevId: 498426185
using the "RotRight7" decoder. The "shldq" technique is much faster on recent
Intel and AMD CPUs, when processing larger integers, especially on Zen.
PiperOrigin-RevId: 498078103
qualified type name (ie starts with `.`).
This way we guarantee that the spelling the `.proto` file will be the same as
the spelling we see after crosslinking types.
Otherwise, the spellings might differ and it makes it harder to determine if
the name in the allowlist matches the name in the `.proto` file.
PiperOrigin-RevId: 497997383
We would like for upb_Map_Delete() to optionally return the deleted value.
Unfortunately this will require several steps since we are crossing repos.
Step #2: Point PHP and Ruby at the new temporary function.
point the protobuf repo at latest upb
regenerate the amalgamation files
PiperOrigin-RevId: 497310441
It's quite common that fields in its proto description usually appear in the tag increasing order and thus let's use this assumption and do not call std::sort more than needed. Also calls to std::sort on smaller ranges as extension tags are almost always bigger and they are returned in their increasing order.
PiperOrigin-RevId: 497123665
These files get automatically updated as post-submit actions, and there's no reason to ever used the checked in versions. Daily run staleness test verify that those don't go out of date.
PiperOrigin-RevId: 496800868
It looks like Bazel 6.0 changed the stringification of Label objects:
b1113f801d
That is causing some problems for our staleness test, since different
Bazel versions get different results. This CL fixes the problem by
tweaking the logic so that we explicitly format the label string.
PiperOrigin-RevId: 496790722
This is not all of the logic, since there are places in message.cc that inadvisedly reach into field variables, and only primitive_field.cc is ported to the new system in this CL, as an example.
There are various unrelated-looking changes in this CL that are actually required to keep it a no-op, which are a product of the implicit dependencies between different parts of the backend.
PiperOrigin-RevId: 496770877
This CL:
* Does the aforementioned.
* Deletes all of the associated headers and moves the implementation class definitions into the .cc files.
* Exposes factory functions for all the different FieldGenerator implementations.
This change will be followed up by parallel changes that clean up individual .cc files to delete redundant code. This change reduces what files need to be updated in future FieldGenerator refactors, and places them in a central location for this. Finally, because these classes only exist to implement FieldGenerator, they should not expose any other API for other parts of the compiler to use.
PiperOrigin-RevId: 496722868
Prepare protobuf for bzlmod
Self-reference to `@com_google_protobuf` doesn't work with bzlmod.
In case this is a rule attribute, no reference is needed.
When the label is a default parameter value in a macro it needs to be wrapped with `Label` call, to relativise it correctly.
PiperOrigin-RevId: 496687786
Release notes from https://github.com/protocolbuffers/protobuf/releases should be the singular source of truth for release changelogs. Post-Copybara, this file is no longer needed to stage changes from syncs for the next release.
PiperOrigin-RevId: 496683510
Currently, FieldGenerator holds onto a bit of state, and due to the way its interface is constructed it results in untracked dependencies between the contents of map<string, string> values that get tossed around the compiler. In order to break these dependencies, we want to move calculation of string variables into a centrally tracked place, but that requires inserting variable setup and destruction code in each FieldGenerator call.
Hence, FieldGenerator is replaced with a PIMPL wrapper (FieldGenWrapper) to allow us to do this. Followup CLs will:
* Rename FieldGenWrapper to FieldGenerator and FieldGenerator to some interface-ey name.
* Gradually morph the interface of FieldGenerator to encapsulate all per-field logic, so that message.cc does not have to iterate over fields except to call into generators, and as such does not need to manipulate per-field substitution variables.
This CL is a no-op refactor.
PiperOrigin-RevId: 496489306
This is part of the Printer::Emit() migration, since it allows us to drop some relatively complex logic out of ClassVars/FieldVars, which is an impediment to further migration of message.cc.
The factored-out logic is not the prettiest, but cleaning it up further will require more refactors throughout the compiler.
This CL also changes std::initializer_lists in Printer's interface into absl::Spans, which were not available when the new Printer API was designed, but which are necessary for the new API to work with Printer.
PiperOrigin-RevId: 496441433
Protobuf Team Bot
Jie Luo
Mike Kruskal
Adam Cozzette
Eric Salo
Deanna Garcia
archpaleus
Protobuf Team Bot
Paul Wankadia
Sandy Zhang