Properly handle package-default visibility in AggregatingAttributeMapper Have `#visitAttribute` recognize that visibility is special, which lets it play nice with the `attr` query function and lets us delete `#getPossibleAttributeValues`. We check for the visibility special case after checking for selects and computed defaults - visibility shouldn't be either of these, but stranger things have happened. I think the history here is that package-default visibility was always broken for the `attr` query function, which uses `#visitAttribute`, while query output was correct because it used #getPossibleAttributeValues (or other scattered special-casing which existed at various times). rule_test_test needed to be updated because it was expecting the broken behavior - package-default visibility being ignored by `attr(...)`. PiperOrigin-RevId: 309477218
{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:
See CONTRIBUTING.md