When a file doesn't have a proto package, allow validation to still be supported
via entries with that consist of 'no_package:FILE'. This allows someone using an
expected prefixes file to also list these exceptional cases, and allows them to
becomes error cases with requiring all prefixes to be registered.
* fix C# aarch64 test after .NET SDK upgrade
* simplify C# aarch64 tests (net60 can build under emulator)
* Revert "simplify C# aarch64 tests (net60 can build under emulator)"
This reverts commit 6b2aa5f006.
These are still x86-64 binaries at the moment (see #8557), but should be
usable on M1 Macs in the Rosetta compatibility mode. Let's start
publishing them on our GitHub release page and then eventually we can
make them into true aarch_64 binaries.
This fixes#9200.
* Creates a protoc release zip
Mimics what we're doing manually today but powered by Bazel.
* don't special case this.
* Addressing feedback.
* adding comment about _cc_toolchain
* Use repo-relative labels wherever possible
The label `@com_google_protobuf//:foo` within the protobuf repo is often synonymous with just `//:foo`. We should prefer the latter as it allows us to use a shorter name for the module in the Bazel Central Registry (so just "protobuf" instead of "com_google_protobuf").
Note that the semantics can be subtle: in a macro, plain strings are anchored to the *calling* repo, so if we just use `//:foo` as the default value of a macro argument, it will be resolved to `@myrepo//:foo` if the macro is called from the repo `@myrepo`. In this case, it's necessary to directly call the `Label()` constructor to anchor the string label to the repo where the .bzl file lives.
See https://github.com/bazelbuild/bazel-central-registry/pull/28#issuecomment-954741081 for a bit more context.
* fix protobuf_deps.bzl