This didn't require any change to the algorithm, except to mark one extra (immutable) member as atomic. It did require changing the tests though.
PiperOrigin-RevId: 690751567
For most _native_ loads of Java rules (e.g. java_library), these can be automatically handled by Bazel 8's autoload feature.
However, this is not the case when the main repository (IOW, the repository currently being built) is a rule repo itself. In those cases, module dependencies are not automatically loaded.
This PR fixes a compatibility issue of OSS protobuf Bazel rules with other Bazel rule repositories such as bazelbuild/rules_android.
Without this PR, builds within rules repositories with Bazel 8 will fail like so:
```
external/protobuf+/java/core/BUILD.bazel:142:13: @@protobuf+//java/core:lite: no such attribute 'srcs' in 'java_library' rule
```
PiperOrigin-RevId: 690735533
The pre-release version was printed even if it was blank. Move the message inside a pre-existing if condition so it'll only get printed if it's set.
Closes#18958
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/18958 from imrichardcole:task/remove-blank-printing f0dd1d938b
PiperOrigin-RevId: 690727280
Note:
This change primarily affects debug + ASAN builds using protobuf arenas.
If this change causes a crash in your debug build, it probably means that
there is a use-after-free bug in your program. This change has already been
implemented and battle-tested within Google for some time.
Oneof messages on the regular heap should not be affected because the memory
they hold are already deleted. Users will already see use-after-free errors
if they attempt to access heap-allocated oneof messages after calling Clear().
When a protobuf message is cleared, all raw pointers should be invalidated
because undefined things may happen to any of the fields pointed to by
mutable_foo() APIs. While destructors may not necessarily be invoked, Clear()
should be considered a pointer invalidation event.
#test-continuous
PiperOrigin-RevId: 689569669
When generating `-I` arguments from `ctx.attr.includes` in
`_proto_gen_impl()`, we might find '.' in the list. That's effectively
source_dir, which we've already handled earlier, and has more
specialized expansion code. Skip it here.
#test-continuous
PiperOrigin-RevId: 689557912
are enabled.
This makes the function a drop-in replacement for `dynamic_cast` when the user
is expecting exceptions to be thrown.
PiperOrigin-RevId: 689419852
Have ExtensionIdentifier have a upb_MiniTableExtension* instead of subclassing a class that is just a plain holder for a upb_MiniTableExtension* with a getter with the same name
We generally want to lean toward composition over inheritance. Without a compelling reason for inheritance, let's prefer composition for clarity, flexibility, and evolvability. Locking oneself into an inheritance hierarchy has marred many a codebase.
PiperOrigin-RevId: 689380813
The JVM regex engine allocates garbage on every match (especially when calling Matcher.usePattern!). Since there are expected to be a lot of tokens, this caused substantial GC overhead.
Direct char scanning also opens the possibility of other optimizations that aren't possible with regexes. For example:
- direct reads from a char[]
- streaming tokenization (rather than reading the complete source text)
PiperOrigin-RevId: 689230675
Without this, `cargo test` tries to extract all rustdoc comments and run them as a unit test. For these snippets, we can't easily actually make such a snippet work, as they explain how codegen would be used.
PiperOrigin-RevId: 688643028
This required making a shim file for a crate to be able to re-export either the _cpp or _upb impl so that it can be one crate that conditionally delegates to the intended one.
PiperOrigin-RevId: 688639897
By just checking for upper-cased characters, rather than digits and lower-cased characters, we have to perform fewer comparisons.
This should be safe because absl::AsciiStrToLower only operates on upper-case characters.
PiperOrigin-RevId: 688453016
Clarifies that reordering `enum` fields (even without changing their IDs) will change the order of the `value` indices. (This means that a seemingly "no-op" change to reorganize enums may affect code that (incorrectly) relied on the order of `value()`.
PiperOrigin-RevId: 688297400
It's not used by generated code, contrary to the comment.
The 2-arg version of the method was used in gencode for one day (2025-04-08 through 09): cl/90574926 to cl/90648831.
PiperOrigin-RevId: 688268752
Protobuf Team Bot
Hong Shin
Protobuf Team Bot
Joshua Haberman
Ted Xie
Richard Cole
Sandy Zhang
Mike Kruskal
Chris Kennelly
Tony Liao
nickreid
Jie Luo
Mark Hansen