Chiebot-Mirror/protobuf - protobuf - Gitea: Git with a cup of tea

Author	SHA1	Message	Date
Protobuf Team Bot	426ca8a34a	Move ProtoInfo and ProtoLangToolchainInfo from Bazel The change is no-op for Bazel < 8, it always falls back to native providers. When we cherry-pick --incompatible_autoload_externally to older Bazels, ProtoInfo can be replaced with Starlark implementation, providing that users set the flag so that there is no second implementation exposed from Bazel. PiperOrigin-RevId: 674561141	3 months ago
Joshua Haberman	fd6d8727c8	Created proper `names.h` headers for all upb generators. 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	3 months ago
Joshua Haberman	5ee5891f7d	Refactored the C name mangling to not depend on C++ or upb reflection. This yields several benefits: 1. The code no longer needs to be bootstrapped (since it no longer depends on upb reflection). 2. The upb code generator no longer depends on libprotobuf at all (except for `code_generator_lite.{h,cc}`, which is just one .cc file and has no deps). PiperOrigin-RevId: 672280579	3 months ago
Joshua Haberman	da825e80b1	Migrated upb code generators to the new code_generator_lite.h library. This will remove the dependency on the heavyweight code_generator target. PiperOrigin-RevId: 672093911	3 months ago
Joshua Haberman	e4449ba248	Harmonize license rules between google3 and OSS This simplifies upb by removing differences between google3 and OSS. This also points upb at the protobuf license, instead of keeping a separate copy around for upb. PiperOrigin-RevId: 669447145	3 months ago
Joshua Haberman	ddb863c38e	Moved the C code generator to its own directory. PiperOrigin-RevId: 666928989	4 months ago
Joshua Haberman	c939382705	Split the fasttable-specific code into a separate file. This is a nice split point, since we only need to expose one function to the main generator. PiperOrigin-RevId: 666521717	4 months ago
Joshua Haberman	bc394d2c6d	Moved the MiniTable generator into a separate directory. This is the first in a series of changes intended to improve the code structure of the generator. PiperOrigin-RevId: 666093310	4 months ago