-Zunpretty=expanded
no longer emitting #[cfg(feature = xxx)]
guards?
#139715
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.
Hi there!
I'm trying to track down an issue we're having with
nightly
andcbindgen
in https://github.com/rustls/rustls-ffi. In particular, we rely oncbindgen
'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 oncbindgen
'sparse.expand
functionality, which in turn requires usingnightly
.Sometime recently with a nightly update we observed the generated
.h
produced bycbindgen
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 meanscbindgen
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: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:Instead, this happened: the output with the most recent nightly instead drops the annotation, producing:
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
The text was updated successfully, but these errors were encountered: