Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
cpu opened this issue Apr 12, 2025 · 3 comments
Open

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

cpu opened this issue Apr 12, 2025 · 3 comments
Labels
A-pretty Area: Pretty printing (including `-Z unpretty`) C-bug Category: This is a bug. requires-nightly This issue requires a nightly compiler in some way. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@cpu
Copy link

cpu commented Apr 12, 2025

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

@cpu cpu added C-bug Category: This is a bug. regression-untriaged Untriaged performance or correctness regression. labels Apr 12, 2025
@rustbot rustbot added I-prioritize Issue: Indicates that prioritization has been requested for this issue. needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. labels Apr 12, 2025
@Urgau Urgau added the requires-nightly This issue requires a nightly compiler in some way. label Apr 12, 2025
@Urgau
Copy link
Member

Urgau commented Apr 12, 2025

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
Copy link
Author

cpu commented Apr 12, 2025

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.

@cpu cpu changed the title cargo expand no longer emitting #[cfg(feature = xxx)] guards? -Zunpretty=expanded no longer emitting #[cfg(feature = xxx)] guards? Apr 12, 2025
@cpu
Copy link
Author

cpu commented Apr 12, 2025

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.

@jieyouxu jieyouxu added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Apr 13, 2025
@apiraino apiraino removed the I-prioritize Issue: Indicates that prioritization has been requested for this issue. label Apr 14, 2025
@jieyouxu jieyouxu added A-pretty Area: Pretty printing (including `-Z unpretty`) and removed regression-untriaged Untriaged performance or correctness regression. needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. labels Apr 14, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-pretty Area: Pretty printing (including `-Z unpretty`) C-bug Category: This is a bug. requires-nightly This issue requires a nightly compiler in some way. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

5 participants