It's somewhat tedious to explicitly set this option on all of our C++ targets,
so I think ideally we should rely primarily on bazelrc files for setting
compiler flags. I tried to completely remove `COPTS`, but unfortunately that
did not work out--we have so many `-Wsign-compare` warnings that I think we
need to keep suppressing them for now or else we will get a lot of complaints.
However, I was able to get to the point where `-Wno-sign-compare` is the only
flag we need in `COPTS` for non-Windows builds. I explicitly set `-DHAVE_ZLIB`
on just the two targets that need it, and removed `-Wno-nonnull` since we are
already compliant with that warning. I moved `-Woverloaded-virtual` to our
bazelrc files so that CI will enforce that we remain compliant with that.
PiperOrigin-RevId: 684863987
This doesn't alleviate Bazel's problem. rules_rust are still fetched because they register toolchains themselves.
However the change pushes into the direction, where I believe that only the owning module should be concerned with its toolchain registration and the toolchain selection should be controlled via a flag mechanism or similar. Removing the registration now, can alleviate problems in the future, when we figure out how to prevent unnecessary fetches.
PiperOrigin-RevId: 684721071
Rename bazel_osx_p4deps to for_bazel_tests. The name was used in the past.
Fix all bzl_libraries to have the correct set of dependencies.
Cleanup for_bazel_tests to include BUILD file and public bzl_libraries in the package.
PiperOrigin-RevId: 684713554
The default name for the rules_jvm_external.maven rule is "maven". When not set, it defaults to "maven". For root modules also using rules_jvm_external, the name clash causes a warning:
```
DEBUG: $TMP/external/rules_jvm_external~/private/extensions/maven.bzl:154:14:
The maven repository 'maven' is used in two different bazel modules,
originally in '<my_workspace>' and now in 'protobuf'
```
Summarizing @shs96c in [1]:
> The common maven repo name allows rulesets to contribute to the user's JARs.
> However, this implies that maven is for the end user, not for transitive
> dependencies. If a ruleset needs private dependencies, it should use a custom
> namespace rather than the maven namespace.
Since protobuf is not contributing to user's JARs, we'll use a custom namespace. There's precedent for using a custom namespace for library modules:
- rules_jvm_external uses `rules_jvm_external_deps` instead of `maven`.
- rules_kotlin uses `kotlin_rules_maven` instead of `maven`.
[1]: https://github.com/bazel-contrib/rules_jvm_external/issues/916#issuecomment-1645527584Fixes#16839.
Closes#18641
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/18641 from jschaf:joe/protobuf-maven bd2c62f311
PiperOrigin-RevId: 684625084
When swap is being called on a scalar field in an implicit-presence message,
calling accessors on the swapped-out field should give zero.
When swap is being called on a repeated field in an implicit-presence message,
calling accessors on the swapped-out field should give the empty list.
When swap is being called on a oneof field in an implicit-presence message,
calling `has_foo` on the swapped-out field should return false.
PiperOrigin-RevId: 684582416
These have been empty and forwarding to the real versions for
years now. Everyone should have migrated to the GPB[Name].pbobjc.h
versions instead.
PiperOrigin-RevId: 684580342
As an optimization, we maintain a default instance of a string in memory, and
messages with uninitialized fields will be constructed with a pointer to this
default string object. The destructor should clear the field only when it is
"set" to a nondefault object.
If `ClearNonDefaultToEmpty()` is ever called on a default string...
- It will result in undefined behaviour. Most likely, it results in overwriting
an object in memory (which is already full of zeros) with another bunch of
zeros.
- It's quite bad for a number of reasons:
1. It can confuse TSAN.
2. It blocks us from moving the default instance of the string into the
`.data` section. Having the default instance of the string live in
read-only memory would be beneficial for memory safety. It would play well
with hugepages. It would also eliminate some runtime cost of instantiating
the default instance of the string.
This change adds a debug-fail so that users don't call this function "unsafely".
PiperOrigin-RevId: 684569674
`ProtoStr` is a public type and it has a public
method `to_str`, however `to_str` returns a private
type `Utf8Error`, which triggers `private-interfaces` [1].
Exporting string::Utf8Error makes it possible for other
crates to wrap it in another error type and propagate
it with "?".
[1] https://doc.rust-lang.org/beta/rustc/lints/listing/warn-by-default.html#private-interfaces
PiperOrigin-RevId: 684477510
The fact that our `:protobuf_nowkt` target actually does depend on the
well-known types is causing a dependency cycle for Kythe. This fixes that so
that `:protobuf_nowkt` no longer depends on the well-known types.
PiperOrigin-RevId: 684160567
GPBUnknownFieldSet and the related apis have been replaced by
GPBUnknownFields. The new api allows the Objective-C Protobuf
implementation to be fully conformant around requirements for
parsing/re-serialization of unknown fields.
PiperOrigin-RevId: 684140581
Similar to set_alias for singular submessages, we augment hpb with the ability to add already-allocated messages via the generated function add_alias for repeated messages.
PiperOrigin-RevId: 684136800
Reserved field options used for `protoc-gen-env` and `protoc-gen-default`, implemented here: https://github.com/MarnixBouhuis/confpb
I've recently released a protoc plugin for generating defaults / binding environment variables to go protobuf structs. For this I would like to reserve the field options used.
Closes#18507
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/18507 from MarnixBouhuis:patch-1 63e3440062
PiperOrigin-RevId: 684103559
If the first check passed (we're an ArrayList) then we aren't a ProtobufArrayList, and there's no point checking.
Micro-optimisation.
PiperOrigin-RevId: 683793700
I think all these generics only change things at compile-time, not at runtime. So should be safe.
It's not a huge win; there's still some unchecked casts. But I was able to remove some unchecked casts, and some warning suppressions, so it's incrementally better.
PiperOrigin-RevId: 683793374
Adam Cozzette
Thomas Van Lenten
Protobuf Team Bot
Benjamin Peterson
Joe Schafer
Mark Hansen
Tony Liao
Hong Shin
Noah Watkins
Mike Kruskal
Protobuf Team Bot
Marnix Bouhuis
y-yagi
Anuraag (Rag) Agrawal
Xufei Tan