Document behaviour of `None` with `attr` related API Relates to #23547 `tag_class` is unique in a few ways to other functions that accept an attribute spec from the `attr` module. 1. It does not return a callable, but rather value containing metadata for `module_extension.tag_classes`. 2. The defined attributes outright reject `None` as a possible value, unlike `rule`, `aspect` and `repository_rule` which all fallback to the default as though no value were provided at all. Supporting `None` makes sense for the other callable results as constructs such as `**kwargs` and functions/macros with default `None` arguments often expose them to such values. Allowing `None` to implicitly mean "use default" is useful in those contexts. This is not the case for `tag _class`, which are interacted with in the extremely restricted context of `MODULE.bazel`. This PR seeks to document how `None` is treated by declared attributes now that behaviour is (intentionally) inconsistent. I also add links from builtin types such as `tag_class` to their factory function (`tag_class()`). Closes #23595. PiperOrigin-RevId: 676066782 Change-Id: Iacc7ca8b7b1560b2b79b7919ceb243504ff0e3cb
{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
