Skip to content

-Zunpretty=expanded no longer emitting #[cfg(feature = xxx)] guards? #139715

Open
@cpu

Description

@cpu

Hi there!

I'm trying to track down an issue we're having with nightly and cbindgen in https://github.com/rustls/rustls-ffi. In particular, we rely on cbindgen's functionality to map Cargo feature flags to C #define's and #if defined(xxx) guards. Since our codebase uses some macros, we also rely on cbindgen's parse.expand functionality, which in turn requires using nightly.

Sometime recently with a nightly update we observed the generated .h produced by cbindgen was no longer producing the required #if defined(XXX) guards.

I believe I've traced this down to something changing in the nightly toolchain such that -Zunpretty=expanded with --features enabled no longer produces expanded code decorated with the #[cfg(feature = "xxx")] annotations. I think this in turn means cbindgen doesn't associate the function with required features.

The reproduction I offer below doesn't use cbindgen at all, and so is hopefully easier to reason about.

Code

I tried cargo rustc --features=turbo-mode -- -Zunpretty=expanded with the following code using nightly:

pub fn add(left: u64, right: u64) -> u64 {
    left + right
}

#[cfg(feature = "turbo-mode")]
pub fn turbo_add(left: u64, right: u64) -> u64 {
    left + right
}

I expected to see this happen: I expected the produced output to show the turbo_add code annotated with the expected #[cfg(feature = "turbo-mode")] annotation:

#![feature(prelude_import)]
#[prelude_import]
use std::prelude::rust_2024::*;
#[macro_use]
extern crate std;
pub fn add(left: u64, right: u64) -> u64 { left + right }

#[cfg(feature = "turbo-mode")]
pub fn turbo_add(left: u64, right: u64) -> u64 { left + right }

Instead, this happened: the output with the most recent nightly instead drops the annotation, producing:

#![feature(prelude_import)]
#[prelude_import]
use std::prelude::rust_2024::*;
#[macro_use]
extern crate std;
pub fn add(left: u64, right: u64) -> u64 { left + right }

pub fn turbo_add(left: u64, right: u64) -> u64 { left + right }

I pushed a simple reproduction repo here: https://github.com/cpu/expand-test

Version it worked on

It most recently worked on: nightly-2025-03-25

Version with regression

The first failure I saw from this was on nightly-x86_64-unknown-linux-gnu - rustc 1.88.0-nightly (1799887 2025-03-29)

Backtrace

N/A

Activity

added
C-bugCategory: This is a bug.
regression-untriagedUntriaged performance or correctness regression.
on Apr 12, 2025
added
I-prioritizeIssue: Indicates that prioritization has been requested for this issue.
needs-triageThis issue may need triage. Remove it if it has been sufficiently triaged.
on Apr 12, 2025
added
requires-nightlyThis issue requires a nightly compiler in some way.
on Apr 12, 2025
Urgau

Urgau commented on Apr 12, 2025

@Urgau
Member

I suspect this might be #138844 (cc @petrochenkov).

However I don't think we have any stability guarantee about the nightly only -Zunpretty=expanded flag.

cpu

cpu commented on Apr 12, 2025

@cpu
Author

Sorry, I totally forgot cargo expand isn't first-party 😅

The same issue demonstrates with cargo rustc --features=turbo-mode -- -Zunpretty=expanded. I should have phrased my report without the cargo expand bits.

Edit: updated to remove the cargo expand bits.

changed the title [-]cargo expand no longer emitting `#[cfg(feature = xxx)]` guards?[/-] [+]`-Zunpretty=expanded` no longer emitting `#[cfg(feature = xxx)]` guards?[/+] on Apr 12, 2025
cpu

cpu commented on Apr 12, 2025

@cpu
Author

However I don't think we have any stability guarantee about the nightly only -Zunpretty=expanded flag.

From my perspective this feels less like a stability concern and more like an accuracy concern. IMO the expanded code seems to misrepresent the original source.

added
T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
on Apr 13, 2025
removed
I-prioritizeIssue: Indicates that prioritization has been requested for this issue.
on Apr 14, 2025
added
A-prettyArea: Pretty printing (including `-Z unpretty`)
and removed
regression-untriagedUntriaged performance or correctness regression.
needs-triageThis issue may need triage. Remove it if it has been sufficiently triaged.
on Apr 14, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-prettyArea: Pretty printing (including `-Z unpretty`)C-bugCategory: This is a bug.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.requires-nightlyThis issue requires a nightly compiler in some way.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @cpu@Urgau@apiraino@jieyouxu@rustbot

        Issue actions

          `-Zunpretty=expanded` no longer emitting `#[cfg(feature = xxx)]` guards? · Issue #139715 · rust-lang/rust