Commit Graph

20 Commits (main)

Author SHA1 Message Date
Protobuf Team Bot 396d661767 Add support for setting extensions with Ptr<Extension> in Upb C++ protos.
PiperOrigin-RevId: 633646216
2024-05-14 11:14:58 -07:00
Protobuf Team Bot dbc2baf5bd Generate extension and k[FieldName]FieldNumber as constexpr int(s).
PiperOrigin-RevId: 632173946
2024-05-09 09:26:57 -07:00
Protobuf Team Bot 21d75f861c Remove references to rules_proto
They are not needed after the rules are move into protobuf repo.
Except for the reference to toolchain type, which is currently in rules_proto and can be moved after the implementation is moved into protobuf repo.

PiperOrigin-RevId: 622176865
2024-04-05 07:50:25 -07:00
Protobuf Team Bot d7f032ad15 Move private definitions out of //bazel
This is needed to make protobuf/bazel package minimal for other proto rules.

Keep 4 public bzl files in upb/bazel. They end up under protobuf/bazel, and they are legitimately used by other repositories.

Move upb_proto_library_internal/* under bazel/private. Those are utilities used in the rules. Moving them one level deeper makes protobuf/bazel package clean for other rules.

Move build_defs.bzl and amalgamation under /upb/bazel. Those are utilities used in the build.

Move lua.BUILD and python* uner /python/dist. Those are used in the WORKSPACE dependency setup.

PiperOrigin-RevId: 621442236
2024-04-03 01:37:51 -07:00
Protobuf Team Bot dc5053acc4 Automated Code Change
PiperOrigin-RevId: 621379968
2024-04-02 20:42:07 -07:00
Protobuf Team Bot 83ec410d30 Internal change
PiperOrigin-RevId: 619377672
2024-03-27 05:50:55 -07:00
Derek Mauro b5dcc38679 Automated Code Change
PiperOrigin-RevId: 614655228
2024-03-11 07:36:28 -07:00
Mike Kruskal c78b189609 Internal change
PiperOrigin-RevId: 612549494
2024-03-04 12:44:42 -08:00
Marcel Hlopko 36d344b63f Automated rollback of commit 0ce457f6e7.
PiperOrigin-RevId: 597327159
2024-01-10 12:42:23 -08:00
Protobuf Team Bot 0ce457f6e7 Adds mutable extension accessors to the codegen for upb C and adds a `::protos::MutableExtension` method to upb C++ for getting a mutable extension.
PiperOrigin-RevId: 597088960
2024-01-09 17:23:42 -08:00
Protobuf Team Bot 13b97e1609 Automated Code Change
PiperOrigin-RevId: 595843517
2024-01-04 17:30:18 -08:00
Adam Cozzette a7b0421c78 Breaking change: make protobuf comply with the C++ layering check
This check enforces that each C++ build target has the correct dependencies for
all headers that it includes. We have many targets that were not correct with
respect to this check, so I fixed them up.

I also cleaned up the C++ targets related to the well-known types. I created a
cc_proto_library() target for each one and removed the :wkt_cc_protos target,
since this was necessary to satisfy the layering check. I deleted the
//src/google/protobuf:protobuf_nowkt target and deprecated :protobuf_nowkt,
because the distinction between the :protobuf and :protobuf_nowkt targets was
not really correct. Neither one exposed the headers for the well-known types in
a way that was valid with respect to the layering check, and the idea of
bundling all the well-known types together is not idiomatic in Bazel anyway.
This is a breaking change, because the //:protobuf target no longer bundles the
well-known types. From now on they should be accessed through the new
//:*_cc_proto aliases in our top-level package.

I renamed the :port_def target to :port, which simplifies things a bit by
matching our internal name.

The original motivation for this change was that to move utf8_range onto our CI
infrastructure, we needed to make its dependency rules_fuzzing compatible with
Bazel 6. The rules_fuzzing project builds with the layering check, and I found
that the process of upgrading it to Bazel 6 made it take a dependency on
protobuf, which caused it to break due to layering violations. I was able to
work around this, but it would still be nice to comply with the layering check
so that we don't have to worry about this kind of thing in the future.

PiperOrigin-RevId: 595516736
2024-01-03 15:20:05 -08:00
Protobuf Team Bot 670e0c2a0d Fix begin iterator for empty arrays.
If the underlying array for a repeated field is a nullptr (which is possible for const array access on a message field that hasn't been set) the begin iterator will currently contain garbage data, which can lead to an illegal access. This CL adds a nullptr check to `begin()`, similar to what already exists for `size()`.

PiperOrigin-RevId: 595217999
2024-01-02 15:03:10 -08:00
Adam Cozzette 4ec9170bcd Fix layering check for usage of gtest
To satisfy the layering check, we need to depend on :gtest for the headers, in
addition to :gtest_main which provides the main() function.

There are a bunch of formatting changes as a side effect of this, but they
should be harmless.

PiperOrigin-RevId: 594318263
2023-12-28 14:41:48 -08:00
Eric Salo b997cb6d8d upb: add a non-void typedef for upb_Message
PiperOrigin-RevId: 592863926
2023-12-21 08:12:16 -08:00
Hong Shin c482a8a583 update protos_generator to shortened license
PiperOrigin-RevId: 580934188
2023-11-09 09:33:25 -08:00
Eric Salo 90a7de5063 upb: use upb_c_proto_library() instead of upb_proto_library()
PiperOrigin-RevId: 574674453
2023-10-18 18:37:34 -07:00
xiaolou86 48ebb9b0bb Fix typos (#14409)
Closes #14409

COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/14409 from xiaolou86:main 52126750f0
PiperOrigin-RevId: 574190850
2023-10-17 10:22:51 -07:00
Adam Cozzette 12c7bb0750 Rename `upbc` to `upb_generator`
This makes the file layout a bit more consistent with the `protos ->
protos_generator` pattern. I also replaced the `upbc` namespace with
`upb::generator`.

PiperOrigin-RevId: 569264372
2023-09-28 12:56:03 -07:00
Adam Cozzette 501ececd39 Reorganize upb file structure
This change moves almost everything in the `upb/` directory up one level, so
that for example `upb/upb/generated_code_support.h` becomes just
`upb/generated_code_support.h`. The only exceptions I made to this were that I
left `upb/cmake` and `upb/BUILD` where they are, mostly because that avoids
conflict with other files and the current locations seem reasonable for now.

The `python/` directory is a little bit of a challenge because we had to merge
the existing directory there with `upb/python/`. I made `upb/python/BUILD` into
the BUILD file for the merged directory, and it effectively loads the contents
of the other BUILD file via `python/build_targets.bzl`, but I plan to clean
this up soon.

PiperOrigin-RevId: 568651768
2023-09-26 14:38:35 -07:00