The previous version does not mark the `toolchain_type` as public,
meaning that users of a CC toolchain using
`@rules_cc//cc:toolchain_type` will get build errors along the lines of
```
ERROR:
.../local_config_cc_toolchains/BUILD.bazel:18:1:
in toolchain rule
@local_config_cc_toolchains//:cc-toolchain-armeabi-v7a: alias
'@rules_cc//cc:toolchain_type' referring to target
'@bazel_tools//tools/cpp:toolchain_type' is not visible from target
'@local_config_cc_toolchains//:cc-toolchain-armeabi-v7a'. Check the
visibility declaration of the former target if you think the dependency
is legitimate
```
* Simplified PHP testing scripts.
- allow them to be run from any directory.
- remove "VERSION" arg, we can get PHP from $PATH.
* Added a few places I missed.
* Removed redundant "cd `dirname $0`".
Also replaced all backticks with $(), for consistency.
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)
