bazel: incompatible_remove_rule_name_parameter

The rule.name was never designed to support “anonymous rules” or to fix problems how rule classes are defined. I can see how it became useful, but I think those uses still look very 'workaroundish". There is also the problem that the name appears in queries and is used by the tools to recognize the rule - only the name part, not the ‘bzl’ file the rule is in.

I believe the problems you’re stating need be addressed and they need to be addressed holistically.

rule.name accidentally solves them, but only partially. This will make the complete solution more difficult. And the implementation has other problems I mentioned before.

Sorry, but it’s going away.

The status quo ante causes serious user confusion and frequent problems where rule authors do not realize that the name given to the left hand side of the rule assignment is part of that rule’s public API no matter how many underscores they put in front of it or how many layers of macros they bury it in. This causes real problems when rule authors refactor their rules and think that the “public” macro is the only relevant aspect.

While this fact exists in the documentation, it is hidden and obscure.

The issue I believe @cpsauer intended to link to is https://github.com/bazelbuild/bazel/issues/14673.

[Hopping in since tagged. Thanks @fmeum.]

I’d like to second that there’s a valuable, fairly broad use case that’d be hampered by the removal of the ability to have “anonymous” rules.

#14673 has all the good details, including a short example, but basically this enabled clean, higher order functions wrapping rule creation. In that case, and with fmeum’s rules_meta, they were enabling easy rule reuse while adding custom configuration to the build graph. More generally, it seems a bit of a bummer to remove the power of higher order functions around rules.

One quick fix might be to automatically export all otherwise-unexported rules under a hash, eliminating the error case completely? Or, to retain the error for true mistakes, to only do so when it has been captured by a function? Or perhaps there’s a more direct way to implement exporting captured rules namelessly?

[@fmeum, am I right that one could work around a removal of lambda-rule functionality manually by returning both the rule and macro to the user, with the instructions to store the rule in an arbitrarily-named, unused variable? Kinda gross to have to expose the implementation like that through the interface…but at least that might not make it a totally hard blocker for rules_meta.]

[Tagging also @gregestren, since he’d been involved in #14673, has thought about this way more than I have, and might be interested. Maybe there are also other, separate solutions in the works that he’d know about.]