cfg attribute expanding before preceding proc_macro_attribute

[Emoun]

I tried this code:

#[duplicate::duplicate_item(
    cfg_filter [all()];
)]
#[cfg(cfg_filter)]
fn my_function() {
    todo!()
}

I expected to see this happen:
The duplicate_item attribute should substitute cfg_filter for all(), meaning my_function should be available use. (see duplicate's documentation).

Instead, this happened:

error[E0425]: cannot find function `my_function` in this scope
  --> src\main.rs:13:2
   |
13 |     my_function()
   |     ^^^^^^^^^^^ not found in this scope

The rust reference states that attributes are expanded in descending order, meaning duplicate_item should be expanded first (which should allow it to affect the cfg attribute). However this doesn't seem to be the case. A current workaround is to put the cfg( part in duplicate_item as well, which stops that attribute from expanding prematurely:

#[duplicate::duplicate_item(
    cfg_filter [cfg(all())];
)]
#[cfg_filter]
fn my_function() {
    todo!()
}

However, my reading of the reference makes me believe this shouldn't be needed.

See also Emoun/duplicate#56 for the original use case. I have simplified it here to highlight the problem.

Meta

rustc --version --verbose:

rustc 1.68.2 (9eb3afe9e 2023-03-27)
binary: rustc
commit-hash: 9eb3afe9ebe9c7d2b84b71002d44f4a0edac95e0
commit-date: 2023-03-27
host: x86_64-pc-windows-msvc
release: 1.68.2
LLVM version: 15.0.6
-------------------------------------------------------------
rustc 1.71.0-nightly (d0f204e4d 2023-04-16)
binary: rustc
commit-hash: d0f204e4d750b62f9d6c2593405e828757126832
commit-date: 2023-04-16
host: x86_64-pc-windows-msvc
release: 1.71.0-nightly
LLVM version: 16.0.2

Backtrace

<backtrace>

[petrochenkov]

cc #83331

cfg and cfg_attr are currently the only case in which attributes are not expanded in left-to-right order, but we cannot change it due to backward compatibility.

One more workaround is to make a custom proc macro my_in_order_cfg that will expand to regular cfg.
It will expand in-order in this case.

[Emoun]

@petrochenkov yes, it seems this is a duplicate of #83331 so I will close this issue.

Thanks for the quick reply.