Bazel Rules

### Overview In this talk, Evo presents the ongoing evolution of Bazel rules across past, present, and future initiatives. Bazel rules constitute a major, extensible portion of the Bazel codebase that enables support for arbitrary programming languages. The presentation outlines the Starlarkification effort to migrate legacy Java-based native rules to Starlark, details new APIs currently being developed to extend and structure rules, and shares future roadmap goals focused on performance, modularity, and language usability.

### Key Topics - **Starlarkification of Native Rules**: Transitioning roughly 250,000 lines of implementation code (380,000 including tests) written in Java into Starlark, carried out by a small team at Google (typically one person per language). - **Layered Migration Strategy**: Converting rules from outer layers (rule definitions) to middle layers (shared implementations like `JavaInfo`, `java_common`, `cc_common`), and finally inner layers (language-specific actions). - **Rule Maintenance and Repository Splitting**: Preparing to move rule sets out of the core Bazel repository into separate repositories owned by language toolchain experts and maintained alongside the community, while avoiding forks. - **New APIs for Extension and Structuring**: Introducing rule inheritance/extension APIs and encapsulated `subrule` constructs to reduce code duplication and enforce coding standards. - **Future Plans and Performance**: Exploring a minimal standard build library, include scanning improvements, first-class symbolic macros to reduce peak memory consumption, and potential type annotations in Starlark.

### Technical Details - **Starlarkification Progress by Language**: Proto rules are completely rewritten across all layers. Python rules are nearly complete with all layers covered, though relying on some private APIs requiring cleanup. Java rules are converted through the middle layer (with `JavaInfo` now backed by proto info in Starlark), leaving the specific Java compile action for later. Android rules, handled by Alex, are largely rewritten directly in repositories with `android_binary` remaining as an essential piece. C++ rules are the most complex; the outer layer is complete, and the middle layer rewrite is actively ongoing. - **Rule Extension API**: Designed to stop teams from creating unmaintainable forks. Users and Google teams define baseline rules (e.g., standard `java_library`) and create custom extensions (such as `google_java_library`). An extension rule defines its own implementation, merges or overrides public attributes (e.g., attaching aspects), calls `ctx.super()` exactly once to obtain parent providers, and can add actions or augment providers (such as modifying `DefaultInfo`). - **Subrules API**: Designed to enforce coding guidelines and code reuse through strict encapsulation. A subrule (illustrated with an `android_lint` example) defines its own implementation and private/implicit tool dependencies. It receives a restricted context without rule attributes, can declare actions, manipulate providers, or invoke other subrules, and is explicitly declared on the parent rule. - **Roadmap & Memory Optimization**: An experimental implementation of rule extension and subrules is being targeted for Bazel 7 under an experimental flag. Additional initiatives include first-class symbolic macros that enforce naming prefixes and reduce peak RAM usage, investigating target visibility within macros, and exploring Starlark type annotations to reduce rule definition boilerplate.

### Takeaways - Bazel's native Java rules are steadily moving into Starlark, yielding lower memory footprints in certain cases and enabling future separation from Bazel core releases. - Forking rule sets creates severe long-term maintenance burdens; Bazel is addressing this by providing native rule extension mechanisms so baseline rules can be augmented safely. - Subrules provide a structured, encapsulated way to break down complex rule implementations without sharing unrestricted context or private tool attributes. - Memory consumption remains a primary operational challenge in Bazel, driving innovations like symbolic macros alongside long-term goals for a small, stable standard build library.