| commit | 535a0cebe2b8baa107fe8d1b90ef2d555f512ad1 | [log] [tgz] |
|---|---|---|
| author | Googler <brandjon@google.com> | Thu Oct 06 11:33:12 2022 -0700 |
| committer | Copybara-Service <copybara-worker@google.com> | Thu Oct 06 11:34:45 2022 -0700 |
| tree | ce0f9a5c03631709953461a3f0cd25d4c6958b8a | |
| parent | 1473988aa1e9b92c42fcbad4e155f247f1983d13 [diff] |
Simplify visibility() arg parsing logic, support visibility("//foo")
BazelBuildApiGlobals:
- An arg of "some_string" is treated as syntactic sugar for ["some_string"]. This supports args of form "//foo".
- Deleted special casing for "public" and "private". These are now handled by the sugar and by the new PackageSpecification syntax added in unknown commit.
BzlLoadFunctionTest:
- Add tests for `visibility([])`, `visibility("//foo")`, and the unsupported case of negated package specs
BzlVisibility:
- Add interning of special public/private cases; lift construction to factory method.
- Rename PackageListBzlVisibility since it's really package specifications, not packages being listed. Make private since users don't need direct access to it. (Kept PUBLIC/PRIVATE singletons as public since it's reasonable for client code to directly refer to those.)
Since it's likely we won't support negation, we could even eliminate the BzlVisibility class altogether in favor of lists of PackageSpecifications. This would simplify interning of public/private (but complicate any hypothetical future interning of non-trivial allowlists). But having a separate class is more convenient/readable for the bzl machinery.
StarlarkBuildApiGlobals:
- Move description of valid visibility() arg values to the arg's doc.
- Condense the mention of the distinction between bzl-visibility and target visibility.
- Mention behavior relative to --incompatible_fix_package_group_reporoot_syntax.
Work toward #11261.
PiperOrigin-RevId: 479369691
Change-Id: Ib9b2844abc03b0596399cc3fe09e9b89c6416e90
{Fast, Correct} - Choose two
Build and test software of any size, quickly and reliably.
Speed up your builds and tests: Bazel rebuilds only what is necessary. With advanced local and distributed caching, optimized dependency analysis and parallel execution, you get fast and incremental builds.
One tool, multiple languages: Build and test Java, C++, Android, iOS, Go, and a wide variety of other language platforms. Bazel runs on Windows, macOS, and Linux.
Scalable: Bazel helps you scale your organization, codebase, and continuous integration solution. It handles codebases of any size, in multiple repositories or a huge monorepo.
Extensible to your needs: Easily add support for new languages and platforms with Bazel's familiar extension language. Share and re-use language rules written by the growing Bazel community.
Follow our tutorials:
To report a security issue, please email security@bazel.build with a description of the issue, the steps you took to create the issue, affected versions, and, if known, mitigations for the issue. Our vulnerability management team will respond within 3 working days of your email. If the issue is confirmed as a vulnerability, we will open a Security Advisory. This project follows a 90 day disclosure timeline.
See CONTRIBUTING.md
