bazelbuild / bazelbuild/stardoc
Expose whether an attribute is inherited
- Dominant language
- Java
- Stars
- 118
- Forks
- 51
- PR merge metrics
- No merged PRs in 30d
Description
It's useful to expose whether an attribute is defined directly in a macro or rule class, or inherited (via `inherit_attrs` for a macro or `parent` for a rule). This would allow us to create less-fragile golden tests - ones which don't break every time Bazel changes a doc string for some attribute inherited by the macro or rule under test.
Doing this requires a change to `starlark_doc_extract` proto output, and to AttributeProvider.java logic in Bazel source.
An open question is whether it's sufficient to expose a binary status (inherited / not inherited), or if we want to expose the *provenance* of an attribute (e.g. if it was inherited from macro M which inherited in turn from rule R, we expose the fact that it originates from rule R). Note that in Bazel, this provenance information would have to be attached to AttributeProvider, not to the attribute object, because (a) the same Attribute object is shared by unrelated rules or macros (e.g. under "manual" attribute inheritance via a shared dict of attribute objects), and (b) in the macro attribute inheritance mechanism we sometimes have to clone and modify an attribute object, but morally consider it to still have been inherited.
@brandjon FYI
Contributor guide
Research direction
Start by reading AttributeProvider.java and the starlark_doc_extract proto definition to understand how attributes are represented and exported. Resolve whether the output should expose only inherited status or full provenance, then update both Bazel-side logic and proto output so golden tests can distinguish directly defined attributes from inherited ones.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- tooling
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100