-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Symbolic macro attribute inheritance #24066
Comments
Instead of Alternatively, don't support that at all, and require the rule author to fail if "cxxopts" is a key of **kwargs. Honestly, that seems more minimalist and safer than adding a new None value type to attrs. Do we have evidence that this use case is common? Can we afford to punt on it? |
Note that |
What would the syntax be for inheriting common attrs (of all rules, test rules, or binary rules) without inheriting the specific attrs added by any particular rule? I'm also worried that the idea of common attrs as documented in the Build Encyclopedia might be a fiction -- it's assembled from some seemingly manually curated template content, rather than extracted from a source of truth in code. So there may in fact be many more than three particular sets of predeclared rule attrs. Also the attrs for e.g. native binary rules and starlark binary rules may be subtly different. All of this is to say that perhaps we shouldn't yet support this use case, and instead require the user to name a particular rule. |
For consistency, I'd prefer to keep the shape of the
An internal user explicitly requested a way to hide attributes. Marking attributes as illegal via implementation
Good question! My plan was to use special string constants - e.g.
Good question! And the answer, I think, is to explicitly state that |
@brandjon - good idea, I agree (as discussed offline). |
@bazel-io fork 8.0.0 |
Allows the following syntax: ``` my_cc_library = macro( # inherit all attributes from a given rule or macro symbol (or "common" for # the set of common Starlark rule attributes) inherit_attrs = native.cc_library, attrs = { # remove cxxopts from inherited attrs list "cxxopts": None, # override the copts attribute inherited from native.cc_library "copts": attr.string_list(default = ["-D_FOO"]), }, ... ) ``` Fixes bazelbuild#24066 Tricky parts: * Some common rule attributes ("testonly", "size", etc.) have computed defaults; native rule "license" and "distribs" attrs have defaults which fail type check if lifted. The only sane way of handling such attrs, if the attribute is unset in the macro function call, to pass the value as None to the implementation function so that the implementation function will pass None to the rule function, which will thus set the default appropriately. * We need RuleFunctionApi and MacroFunctionApi interfaces (yet more interfaces, alas, or we get a circular dependency) to express the type of inherit_attrs param * Iterating over all native rules (for testing inheritance from them) is tricky: we need to look at builtins (since the ConfiguredRuleClassProvider may have stubs for java rules overridden by builtins). This is already correctly handled by `bazel info build-language`, so let's move the logic into a utility class. RELNOTES: Add inherit_attrs param to macro() to allow symbolic macros to inherit attributes from rules or other symbolic macros. PiperOrigin-RevId: 694154352 Change-Id: I849a7f16b4da8eb2829cdbc6a131d85a28bc4740
Allows the following syntax: ``` my_cc_library = macro( # inherit all attributes from a given rule or macro symbol (or "common" for # the set of common Starlark rule attributes) inherit_attrs = native.cc_library, attrs = { # remove cxxopts from inherited attrs list "cxxopts": None, # override the copts attribute inherited from native.cc_library "copts": attr.string_list(default = ["-D_FOO"]), }, ... ) ``` Fixes #24066 Tricky parts: * Some common rule attributes ("testonly", "size", etc.) have computed defaults; native rule "license" and "distribs" attrs have defaults which fail type check if lifted. The only sane way of handling such attrs, if the attribute is unset in the macro function call, to pass the value as None to the implementation function so that the implementation function will pass None to the rule function, which will thus set the default appropriately. * We need RuleFunctionApi and MacroFunctionApi interfaces (yet more interfaces, alas, or we get a circular dependency) to express the type of inherit_attrs param * Iterating over all native rules (for testing inheritance from them) is tricky: we need to look at builtins (since the ConfiguredRuleClassProvider may have stubs for java rules overridden by builtins). This is already correctly handled by `bazel info build-language`, so let's move the logic into a utility class. RELNOTES: Add inherit_attrs param to macro() to allow symbolic macros to inherit attributes from rules or other symbolic macros. PiperOrigin-RevId: 694154352 Change-Id: I849a7f16b4da8eb2829cdbc6a131d85a28bc4740 Commit eec5305 Co-authored-by: Googler <[email protected]>
…al_enable_macro_inherit_attrs flag We still have open questions about how macro attribute inheritance ought to interact with the tracking of whether rule attributes were or were not explicitly provided. In effect, this re-opens #24066 Part of addressing #24319 RELNOTES: symbolic macro attribute inheritance is now marked experimental; set --experimental_enable_macro_inherit_attrs flag to enable it. PiperOrigin-RevId: 696582223 Change-Id: I3d7cb434bf8fe2da9cd10019e6075990205e7153
@bazel-io fork 8.0.0 |
…perimental_enable_macro_inherit_attrs flag (#24336) We still have open questions about how macro attribute inheritance ought to interact with the tracking of whether rule attributes were or were not explicitly provided. In effect, this re-opens #24066 Part of addressing #24319 RELNOTES: symbolic macro attribute inheritance is now marked experimental; set --experimental_enable_macro_inherit_attrs flag to enable it. Commit 08beb21 PiperOrigin-RevId: 696582223 Change-Id: I3d7cb434bf8fe2da9cd10019e6075990205e7153 Working towards #24335
It did not and cannot work; I was misled by an incorrect test. (So take the opportunity to fix the tests.) Working towards #24066 PiperOrigin-RevId: 696954211 Change-Id: Ia205fe4e6686d51248c1389e1cf7b826650908e8
…utes to None This fixes two problems: * Various attributes (e.g. compatible_with, restricted_to, shard_count, genrule's cmd and cmd_bat, etc.) have hard-coded analysis-time behavior in Bazel which differs depending on whether the attribute was unset (or set to None) or set to any other value (including the attribute's non-None default!). Using the original default value for such an inherited attribute and passing it to the wrapped rule would in many cases break the build. * The fact that an attribute was set explicitly is reflected in query proto and xml output. In a legacy macro that wraps a rule and passes the bulk of them via **kwargs, it is expected that most of the **kwargs will be empty and most of the wrapped rule's attributes will thus be not explicitly set. We want to preserve the same behavior in symbolic macros. Working towards #24066 Fixes #24319 PiperOrigin-RevId: 697301269 Change-Id: I47563898c511a1f065d117f51a7a3a227e23260e
…cros It did not and cannot work; I was misled by an incorrect test. (So take the opportunity to fix the tests.) Working towards bazelbuild#24066 Cherry-pick of bazelbuild@372980c PiperOrigin-RevId: 696954211 Change-Id: Ia205fe4e6686d51248c1389e1cf7b826650908e8
…d attributes to None This fixes two problems: * Various attributes (e.g. compatible_with, restricted_to, shard_count, genrule's cmd and cmd_bat, etc.) have hard-coded analysis-time behavior in Bazel which differs depending on whether the attribute was unset (or set to None) or set to any other value (including the attribute's non-None default!). Using the original default value for such an inherited attribute and passing it to the wrapped rule would in many cases break the build. * The fact that an attribute was set explicitly is reflected in query proto and xml output. In a legacy macro that wraps a rule and passes the bulk of them via **kwargs, it is expected that most of the **kwargs will be empty and most of the wrapped rule's attributes will thus be not explicitly set. We want to preserve the same behavior in symbolic macros. Working towards bazelbuild#24066 Fixes bazelbuild#24319 Cherry-pick of bazelbuild@a2f1f58 PiperOrigin-RevId: 697301269 Change-Id: I47563898c511a1f065d117f51a7a3a227e23260e
…al_enable_macro_inherit_attrs flag We still have open questions about how macro attribute inheritance ought to interact with the tracking of whether rule attributes were or were not explicitly provided. In effect, this re-opens #24066 Part of addressing #24319 RELNOTES: symbolic macro attribute inheritance is now marked experimental; set --experimental_enable_macro_inherit_attrs flag to enable it. PiperOrigin-RevId: 696582223 Change-Id: I3d7cb434bf8fe2da9cd10019e6075990205e7153
@tetromino Any reason not to close this issue? |
Allows the following syntax: ``` my_cc_library = macro( # inherit all attributes from a given rule or macro symbol (or "common" for # the set of common Starlark rule attributes) inherit_attrs = native.cc_library, attrs = { # remove cxxopts from inherited attrs list "cxxopts": None, # override the copts attribute inherited from native.cc_library "copts": attr.string_list(default = ["-D_FOO"]), }, ... ) ``` Fixes bazelbuild#24066 Tricky parts: * Some common rule attributes ("testonly", "size", etc.) have computed defaults; native rule "license" and "distribs" attrs have defaults which fail type check if lifted. The only sane way of handling such attrs, if the attribute is unset in the macro function call, to pass the value as None to the implementation function so that the implementation function will pass None to the rule function, which will thus set the default appropriately. * We need RuleFunctionApi and MacroFunctionApi interfaces (yet more interfaces, alas, or we get a circular dependency) to express the type of inherit_attrs param * Iterating over all native rules (for testing inheritance from them) is tricky: we need to look at builtins (since the ConfiguredRuleClassProvider may have stubs for java rules overridden by builtins). This is already correctly handled by `bazel info build-language`, so let's move the logic into a utility class. RELNOTES: Add inherit_attrs param to macro() to allow symbolic macros to inherit attributes from rules or other symbolic macros. PiperOrigin-RevId: 694154352 Change-Id: I849a7f16b4da8eb2829cdbc6a131d85a28bc4740
…al_enable_macro_inherit_attrs flag We still have open questions about how macro attribute inheritance ought to interact with the tracking of whether rule attributes were or were not explicitly provided. In effect, this re-opens bazelbuild#24066 Part of addressing bazelbuild#24319 RELNOTES: symbolic macro attribute inheritance is now marked experimental; set --experimental_enable_macro_inherit_attrs flag to enable it. PiperOrigin-RevId: 696582223 Change-Id: I3d7cb434bf8fe2da9cd10019e6075990205e7153
It did not and cannot work; I was misled by an incorrect test. (So take the opportunity to fix the tests.) Working towards bazelbuild#24066 PiperOrigin-RevId: 696954211 Change-Id: Ia205fe4e6686d51248c1389e1cf7b826650908e8
…utes to None This fixes two problems: * Various attributes (e.g. compatible_with, restricted_to, shard_count, genrule's cmd and cmd_bat, etc.) have hard-coded analysis-time behavior in Bazel which differs depending on whether the attribute was unset (or set to None) or set to any other value (including the attribute's non-None default!). Using the original default value for such an inherited attribute and passing it to the wrapped rule would in many cases break the build. * The fact that an attribute was set explicitly is reflected in query proto and xml output. In a legacy macro that wraps a rule and passes the bulk of them via **kwargs, it is expected that most of the **kwargs will be empty and most of the wrapped rule's attributes will thus be not explicitly set. We want to preserve the same behavior in symbolic macros. Working towards bazelbuild#24066 Fixes bazelbuild#24319 PiperOrigin-RevId: 697301269 Change-Id: I47563898c511a1f065d117f51a7a3a227e23260e
We want to allow symbolic macros to inherit attributes from a given rule, a given symbolic macro, or the set of common attributes for Starlark rules, Starlark *_test rules, or Starlark *_binary rules. And we'd want the ability to remove or override inherited attributes.
Motivation:
The last point, in particular, would make it vastly easier to migrate legacy macros to symbolic.
I'm thinking of syntax along the following lines:
inherit_attrs
can take either a rule or macro symbol, or the special string constants"common"
,"test"
, or"binary"
to indicate the set of attributes common to all Starlark rules, Starlark test rules, or Starlark binary rules respectively (see https://bazel.build/reference/be/common-definitions).Specifically, the algorithm is as follows:
name
andvisibility
attributes from the inherited list, since symbolic macros auto-inject them"_"
) attributes, since the macro cannot pass them to the wrapped ruleno_inherit_attrs
attrs
dict, withattrs
taking precedence@brandjon @susinmotion FYI
The text was updated successfully, but these errors were encountered: