Envoy was experiencing failed builds due to lots of duplicate -I in the
CLI. The solution is to generally use depset() as per Starlark best
practice for this sort of thing.
Might fix other issues beyond py_proto_library, anything that depends on
proto_gen.
release notes: no
Signed-off-by: Harvey Tuch <htuch@google.com>
A proper integration test should be hermetic such that its operation
is agnostic to whatever happens outside of its controlled environment.
The script is not so since it uses a fixed (and very old) version of Go,
but continues to build protoc-gen-go from head, leading to an eventual
breakage when protoc-gen-go at head no longer operates on such an old
version of Go.
Fix the script to pin to an older version of protoc-gen-go (i.e., v1.3.5).
FieldDescriptor.HasPresence returns true if both ClearValue and HasValue (on the accessor) can be expected to work. Some fields have a working ClearValue, but no HasValue; HasPresence returns false for those fields.
Generally:
- Extension fields have presence if and only if they're singular
- Repeated fields do not support presence
- Map fields do not support presence
- Message fields support presence
- Oneof fields support presence (this includes synthetic oneof fields, so that covers proto3 optional singular fields)
- Proto2 singular primitive fields support presence
- Proto3 singular primitive fields do not support presence (unless they're in a oneof, covered above)
This is a breaking change in terms of proto2 code generation: users who were previously using these members will have to change to null checks for message fields.
After toying with removing Has/Clear for proto2 oneof fields, I've left them alone in this commit, for consistency with other languages. The inconsistency between proto2 and proto3 won't come up here, because proto3 oneof fields can never be explicitly optional.
Fixes#7395.
The primary reason to drop that compatibility is because Bazel is
adding unconditionally -parameters option that is not compatible
with JDK 7. This pollutes the build log with annoying warnings:
warning: -parameters is not supported for target value 1.7. \
Use 1.8 or later.
Second reason is that nobody in the wild relies on JDK 7 any more
because it was discontinued years ago.
Also remove JDK9 config_setting rule that is not used any more.
Test Plan:
Build :protobuf_java and confirm, that there are no warnings any more
and that major byte version 52 is produced, that corresponds to Java 8:
$ bazel build protobuf_java
$ javap -v -cp bazel-bin/java/core/libcore.jar com.google.protobuf.Any | grep major
major version: 52
This was causing problems in OCMock due to recursion when OCMock was trying
to mock a protobuf.
`_forwardStackInvocation:` was being called as part of the resolution of `descriptor`.
There is a note in the documentation to `Reflection::GetRepeatedFieldRef()`
about file `net/proto2/public/reflection.h` which contains a definition of
`RepeatedFieldRef`. Since there are few places in code with rewrite of
`net...` path to `google/protobuf/...` it looks like the first one is a
legacy path and should be renamed to `google/protobuf` in documentation
as well.
FieldDescriptor.HasPresence returns true if both ClearValue and HasValue (on the accessor) can be expected to work. Some fields have a working ClearValue, but no HasValue; HasPresence returns false for those fields.
Generally:
- Extension fields have presence if and only if they're singular
- Repeated fields do not support presence
- Map fields do not support presence
- Message fields support presence
- Oneof fields support presence (this includes synthetic oneof fields, so that covers proto3 optional singular fields)
- Proto2 singular primitive fields support presence
- Proto3 singular primitive fields do not support presence (unless they're in a oneof, covered above)