bazel icon indicating copy to clipboard operation
bazel copied to clipboard

Implement rule extensions

Open comius opened this issue 2 years ago • 4 comments

Checklist:

  • [x] extending from parent
  • [x] calling parent's implementation function (in review)
  • [x] merging public attributes
  • [x] intializers in extended rules
  • [x] limiting rule's extendability
  • [x] stardoc support
  • [x] cfg merging
  • [x] subrules support
  • [ ] handle executable

Design document: https://docs.google.com/document/d/1p6z-shWf9sdqo_ep7dcjZCGvqN5r2jsPkJCqHHgfRp4/edit

comius avatar Sep 13 '23 07:09 comius

@comius where/how do you want bugs for this? We've kicked the tires on it a little and found some friction - our use case is decorating language rule foo_test to provide external dependencies - and had issues with both getting the parent executable cleanly, but also dealing with _allowlist_function_transition in the extended rule.

rbtcollins avatar Dec 30 '23 11:12 rbtcollins

You can open separate bugs or explain more here. I'm aware there might be some problems with executables in executable rules. I'll need to figure this out.

About _allowlist_function_transition. The implicit attribute should be added automatically when a Starlark transition is used. Do you have more specific case where this is causing a problem?

comius avatar Jan 05 '24 14:01 comius

Hello @comius : Thanks for proposing/implementing this feature. However, with current Bazel 7.0.2, the rule extension doesn't work for cc_library, cc_binary and all other CC rules. Bazel aborts with "Private API Usage" error.

Is this by design ? or is it caused because CC rules are still part of the builtins of Bazel and haven't moved to rules_cc ?

I can see that CC Rules are now in Starlark with some reliance on native rules.

omar-droubi avatar Feb 08 '24 08:02 omar-droubi

No, it’s unintentional. C++ rules should be extendable in current form already. I’ll have a look.

comius avatar Feb 16 '24 18:02 comius

@comius I was looking into creating a rule that extends java_library, which I thought would be a supported use case given the number of examples in the design doc that use java_library. Unfortunately, I found that this is not possible (at least on Bazel 7.0.1 with --experimental_rule_extension_api=true):

Error in rule: The rule 'java_library' is not extendable. Only Starlark rules not using deprecated features (like implicit outputs, output to genfiles) may be extended. Special rules like analysis tests or rules using build_settings cannot be extended.

It looks like java_library isn't extendable because it has two implicit outputs. Do you have any plans to support extending rules with implicit outputs, or else remove them entirely from java_library? We'd rather not resort to --experimental_builtins_bzl_path, as the ability to piggy-back off of native rules w/o maintaining our fork of @_builtins is a primary reason why we'd like to use rule extensions in the first place.

timothyg-stripe avatar Mar 05 '24 05:03 timothyg-stripe