Skip to content

nightly featuers: target-specific library features are painful #120930

Open
@RalfJung

Description

@RalfJung

In rust-lang/stdarch#1486, stdarch split up its one uber-feature into a lot of small ones. This led to some rather painful updates. portable-simd now needs code like this to compile:

#![cfg_attr(
    all(
        any(target_arch = "aarch64", target_arch = "arm",),
        any(
            all(target_feature = "v6", not(target_feature = "mclass")),
            all(target_feature = "mclass", target_feature = "dsp"),
        )
    ),
    feature(stdarch_arm_dsp)
)]
#![cfg_attr(
    all(target_arch = "arm", target_feature = "v7"),
    feature(stdarch_arm_neon_intrinsics)
)]
#![cfg_attr(
    any(target_arch = "powerpc", target_arch = "powerpc64"),
    feature(stdarch_powerpc)
)]

I think the main issue is that library features "exist" only if at least one item with that feature exists, so one has to very carefully put cfg_atrr around the feature to avoid "unknown feature" errors. std doesn't have many target-specific features so this is not usually a problem, but for stdarch it is. Additionally, feature attributes must be in lib.rs, so this can't be put inside the modules that actually import these functions -- those modules usually are cfgd, but instead of reusing those cfg we have to repeat them.

Not sure what one could do about this. rustc could ignore unknown features, but that doesn't seem great. Maybe stdarch should have a way to "declare" feature to exist even if no item in the current configuration actually carries that feature? Then portable-simd could just do #![feature(stdarch_arm_dsp, stdarch_arm_neon_intrinsics, stdarch_powerpc)] which would be a lot better.

As a crude hack stdarch could have some "dummy item" for each feature that always exists on all targets, therefore bringing the library feature into existence and letting others enable it in a cfg-independent way.

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-discussionCategory: Discussion or questions that doesn't represent real issues.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions