-
Notifications
You must be signed in to change notification settings - Fork 516
Description
Bug Description
When using default_alias_rule_bzl in crate_universe configuration, Bazel fails to build targets that depend on aliased crates. The error occurs in the aliases() function when it tries to reference crate_info.owner for aliased targets, but the aliased target's crate_info has a different structure than expected.
Environment
- Bazel version: Multiple versions affected
- rules_rust version: Multiple versions affected
- Operating system: Cross-platform issue
Reproduction Steps
-
Configure
crate_universewithdefault_alias_rule_bzl:crates_repository( name = "crate_index", # ... other config ... render_config = render_config( default_alias_rule_bzl = "opt", ), )
-
Use a crate that creates aliased targets in the generated BUILD files
-
Try to build a target that uses the
aliases()function -
Observe build failure in the generated aliases() function
Error Details
The issue manifests in the generated code in rust/private/rustc.bzl at approximately line 255:
# Current problematic code:
for k, crate_info in crate_infos.items():
# For aliased crates, crate_info.owner may not match k.label
# This causes inconsistencies in alias generationWhen default_alias_rule_bzl is used, the system generates aliased targets, but the alias resolution logic doesn't correctly handle the relationship between the aliased target's label (k.label) and its underlying crate info owner (crate_info.owner).
Root Cause
The problem occurs because:
default_alias_rule_bzlcreates alias targets that wrap the actual crate targets- The current logic in
rustc.bzlassumes a direct correspondence between target labels and crate_info owners - For aliased targets,
crate_info.ownerpoints to the original target, not the alias label - This mismatch breaks the alias generation logic
Proposed Fix
The fix should handle the case where aliased crates have different owner values in their crate_info:
# Proposed fix in rust/private/rustc.bzl around line 255:
for k, crate_info in crate_infos.items():
# Handle aliased crates where crate_info.owner != k.label
owner_label = crate_info.owner if hasattr(crate_info, 'owner') else k.label
# Use owner_label in subsequent logic instead of assuming k.label == crate_info.ownerImpact
This bug prevents users from leveraging default_alias_rule_bzl functionality in crate_universe, which is intended to provide better integration with existing Bazel rule sets (like @rules_cc) and more consistent alias handling.
Additional Context
This issue affects the core alias generation mechanism in rules_rust and would impact any project trying to use default_alias_rule_bzl with aliased crate dependencies. The fix should maintain backward compatibility while properly handling the aliased crate scenario.
The problem specifically manifests when the crate_universe dependency resolver creates targets with aliased names that don't directly correspond to their underlying crate_info owner labels.