Description
Currently, the deps attribute in rules_rust is overloaded: it accepts both CrateInfo (Rust crates) and CcInfo (C++ libraries).
This overloading creates ambiguity in the dependency model. Specifically, it makes it difficult to link a dependency purely for its native symbols (e.g., satisfying manual FFI via extern "C") without also exposing it as a formal Rust module to the compiler. In large build graphs, this can lead to unnecessary namespace pollution and "leaky" dependency abstractions where internal linkage requirements are exposed as public API dependencies.
Proposed Architectural Change
I propose the introduction of a dedicated link_deps attribute to the core Rust rules (rust_library, rust_binary, rust_test).
Key Goals:
- Explicit intent: Create a clear distinction between
deps (contributing to the Rust module hierarchy) and link_deps (contributing strictly to the linker command line).
- Private Linkage Support: Allow
link_deps to accept both C++ and Rust libraries, but only extract the linkage context (CcInfo). This enables "private" linkage of Rust libraries where binary symbols are satisfied but the crate metadata is hidden from the consumer.
- Non-Breaking addition: Maintain support for C++ libraries in the existing
deps attribute while proactively notifying users (e.g., via analysis-phase warnings) to encourage migration to the more explicit link_deps without breaking current build workflows.
Justification
This feature will eliminate the "silent failure" or cryptic error messages that occur when the wrong type of library is placed in deps. For example, currently, if a cc_library is incorrectly placed in deps, the Bazel analysis phase succeeds, but the build later fails during compilation with a confusing can't find crate for... error from rustc. By separating these concerns, we can provide proactive feedback during the analysis phase.
Impact on Existing Rules
rust_library, rust_binary, rust_test: Gain the link_deps attribute.rust_proc_macro: Intentionally remains focused on host-platform requirements to avoid host-vs-target linkage complexity.- Backward Compatibility: Zero impact on existing builds.
Description
Currently, the
depsattribute inrules_rustis overloaded: it accepts bothCrateInfo(Rust crates) andCcInfo(C++ libraries).This overloading creates ambiguity in the dependency model. Specifically, it makes it difficult to link a dependency purely for its native symbols (e.g., satisfying manual FFI via
extern "C") without also exposing it as a formal Rust module to the compiler. In large build graphs, this can lead to unnecessary namespace pollution and "leaky" dependency abstractions where internal linkage requirements are exposed as public API dependencies.Proposed Architectural Change
I propose the introduction of a dedicated
link_depsattribute to the core Rust rules (rust_library,rust_binary,rust_test).Key Goals:
deps(contributing to the Rust module hierarchy) andlink_deps(contributing strictly to the linker command line).link_depsto accept both C++ and Rust libraries, but only extract the linkage context (CcInfo). This enables "private" linkage of Rust libraries where binary symbols are satisfied but the crate metadata is hidden from the consumer.depsattribute while proactively notifying users (e.g., via analysis-phase warnings) to encourage migration to the more explicitlink_depswithout breaking current build workflows.Justification
This feature will eliminate the "silent failure" or cryptic error messages that occur when the wrong type of library is placed in
deps. For example, currently, if acc_libraryis incorrectly placed indeps, the Bazel analysis phase succeeds, but the build later fails during compilation with a confusingcan't find crate for...error fromrustc. By separating these concerns, we can provide proactive feedback during the analysis phase.Impact on Existing Rules
rust_library,rust_binary,rust_test: Gain thelink_depsattribute.rust_proc_macro: Intentionally remains focused on host-platform requirements to avoid host-vs-target linkage complexity.