This "feature" hasn't been implemented yet, but this puts a placeholder down to prevent compatibility issues in future editions. Once we provide versioning support on individual feature values, we don't want them becoming usable from edition 2023 protos
PiperOrigin-RevId: 635609614
This is an edge case we can't handle properly today. Rather than allowing poorly defined behavior, we'll make this an error condition until we can actually support it. In the future, it may be necessary to upgrade feature files to newer editions.
Closes#16756
PiperOrigin-RevId: 634122584
This prevents shadowing of `java.lang` package commonly used in protobuf gencode. Existing extensions named `java` may or may not previously fail to compile depending on if the contents of their .proto result in gencode using `java.lang`. This is needed to fix `java_features.proto` lite gencode since enum gencode uses `java.lang`. Fields named `java` should already be escaped.
*Warning: This may break user code for existing protos with extensions named `java`. References to the extension should be renamed to use `java_` e.g. registry.add(GeneratedClassName.java_)*
PiperOrigin-RevId: 632508249
* Add temporary alias for system_python.bzl at previous location .
This was added to protobuf_deps.bzl in cl/629786458 and no longer needs to be specified directly in WORKSPACE. However, an alias is needed to prevent users from breaking when upgrading from 26.x -> 27.x due to the obsolete load pointing to the wrong path.
This alias will be removed in a future release, tentatively 4.30.x.
PiperOrigin-RevId: 631821637
* Add upb/bazel/system_python.bzl (new alias file) to upb copybara config.
PiperOrigin-RevId: 631918306
Instead of checking the resolved features, we should really be checking the has_presence helper. Repeated fields, oneofs, and extensions can trigger these conditions when they inherit IMPLICIT, even though it's ignored.
Closes#16664
PiperOrigin-RevId: 630206208
Map fields should remain length-prefixed for now, even if DELIMITED is inherited. Field presence will remain unchanged, but unit-tests are added to make sure proto2/proto3 behaviors stay consistent.
Closes#16549
PiperOrigin-RevId: 630191163
This can cause ODR violations in downstream users who link against both the bootstrapped proto and transitive C++ gencode of java_features.proto. Once protoc is split up, we can turn the bootstrapped proto into a real cc_proto_library target and avoid this problem altogether.
PiperOrigin-RevId: 630099889
This will allow them to reuse our bazelrc and remote caching setup. This also silences the non-bzlmod windows test that's hitting the windows path length.
PiperOrigin-RevId: 626390416
We're seeing a high flake rate due to remote cache-misses only on Bazel 7 builds. The key change here seems to be adding the remote_download_output flag, but this also upgrades us to 7.1.1 and adds some retry behavior to caching issues.
PiperOrigin-RevId: 625892332
Once an edition is released these should be fixed forever. On the other hand, the fixed defaults may see new features included as we change legacy behaviors in future editions.
PiperOrigin-RevId: 625842071
All of this information is still available by merging fixed_features and overridable_features. This new split will make validation easier for runtimes that need to do dynamic builds.
PiperOrigin-RevId: 625815212
Instead of rewriting the field type, just leave it alone. This will only be a potential behavior change for people calling DescriptorPool::InternalSetLazilyBuildDependencies directly. Our normal codegen path already sets field types correctly and is unaffected.
PiperOrigin-RevId: 625807209
Mike Kruskal
Mike Kruskal
zhangskz
Protobuf Team Bot
Joshua Haberman
Joshua Haberman
Protobuf Team Bot
Keith Smiley