-
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
Implement rule extensions #19507
Comments
Add starlarkParent to RuleClass - that's the parent class we need to call. Add ruleClassUnderEvaluation and superCalled to StarlarkRuleContext. This is the new state. Add and implement "super" for StarlarkRuleContextApi. Issue: #19507 PiperOrigin-RevId: 573228317 Change-Id: I35e449cfd31abe6a1801c7dbc4d2016ba532ccb1
@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. |
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 |
Hello @comius : Thanks for proposing/implementing this feature. 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. |
No, it’s unintentional. C++ rules should be extendable in current form already. I’ll have a look. |
@comius I was looking into creating a rule that extends
It looks like |
`cc_binary` has an initializer that may set a private attribute, which is only permitted for built-in rules. The allowlist check always used the outermost rule class, thus failing if `cc_binary` is extended by a non-built-in rule. This is fixed by checking the rule class that actually declares the initializer. Work towards #19507 (comment) Closes #24778. PiperOrigin-RevId: 711361632 Change-Id: I3c0b6e1e6c50fd1af9f1dc635052d0054114ee2d
`cc_binary` has an initializer that may set a private attribute, which is only permitted for built-in rules. The allowlist check always used the outermost rule class, thus failing if `cc_binary` is extended by a non-built-in rule. This is fixed by checking the rule class that actually declares the initializer. Work towards bazelbuild#19507 (comment) Closes bazelbuild#24778. PiperOrigin-RevId: 711361632 Change-Id: I3c0b6e1e6c50fd1af9f1dc635052d0054114ee2d
`cc_binary` has an initializer that may set a private attribute, which is only permitted for built-in rules. The allowlist check always used the outermost rule class, thus failing if `cc_binary` is extended by a non-built-in rule. This is fixed by checking the rule class that actually declares the initializer. Work towards bazelbuild#19507 (comment) Closes bazelbuild#24778. PiperOrigin-RevId: 711361632 Change-Id: I3c0b6e1e6c50fd1af9f1dc635052d0054114ee2d
`cc_binary` has an initializer that may set a private attribute, which is only permitted for built-in rules. The allowlist check always used the outermost rule class, thus failing if `cc_binary` is extended by a non-built-in rule. This is fixed by checking the rule class that actually declares the initializer. Work towards #19507 (comment) Closes #24778. PiperOrigin-RevId: 711361632 Change-Id: I3c0b6e1e6c50fd1af9f1dc635052d0054114ee2d Commit 7093088 Co-authored-by: Fabian Meumertzheim <[email protected]>
Checklist:
Design document: https://docs.google.com/document/d/1p6z-shWf9sdqo_ep7dcjZCGvqN5r2jsPkJCqHHgfRp4/edit
The text was updated successfully, but these errors were encountered: