Skip to content

Error in aliases() when using default_alias_rule_bzl with aliased crates #3692

@ashi009

Description

@ashi009

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

  1. Configure crate_universe with default_alias_rule_bzl:

    crates_repository(
        name = "crate_index",
        # ... other config ...
        render_config = render_config(
            default_alias_rule_bzl = "opt",
        ),
    )
  2. Use a crate that creates aliased targets in the generated BUILD files

  3. Try to build a target that uses the aliases() function

  4. 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 generation

When 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:

  1. default_alias_rule_bzl creates alias targets that wrap the actual crate targets
  2. The current logic in rustc.bzl assumes a direct correspondence between target labels and crate_info owners
  3. For aliased targets, crate_info.owner points to the original target, not the alias label
  4. 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.owner

Impact

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions