Skip to content

Expand #[cfg] and #[cfg_attr] left-to-right for consistency with other attributes #83331

New issue

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

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

Already on GitHub? # to your account

Open
Aaron1011 opened this issue Mar 20, 2021 · 3 comments
Assignees
Labels
A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) C-enhancement Category: An issue proposing an enhancement or a PR with one.

Comments

@Aaron1011
Copy link
Member

Currently, cfg-stripping is performed before we invoke any proc-macro attributes. This means that #[my_attr] #[cfg(FALSE)] struct Foo {} does not invoke #[my_attr] at all, instead of invoking it with #[cfg(FALSE)] struct Foo {}

See https://github.com/rust-lang/rust/pull/82419/files/fc9d578bc5ada5162f49ed02a547cf87f2456a93#r580718089 for a more detailed example and discussion.

@Aaron1011 Aaron1011 added the A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) label Mar 20, 2021
@petrochenkov
Copy link
Contributor

I'm working on this right now.

@petrochenkov
Copy link
Contributor

Crater run in #83354 showed that there's some non-negligible breakage.

In particular, some cases fundamentally require out-of-order expansion like any helper attributes inside cfg_attr

#[derive(Trait)]
#[cfg_attr(predicate, trait_helper)]
struct S;

#[test]
#[cfg_attr(predicate, ignore)]
fn my_test() {}

So they will require using #[cfg_eval] (#82679) if the left-to-right order is enforced by default.

@petrochenkov
Copy link
Contributor

#92473 is the current iteration that attempts to implement some pre-requisites without changing observable language behavior.

bors added a commit to rust-lang-ci/rust that referenced this issue Jan 17, 2022
expand: Pick `cfg`s and `cfg_attrs` one by one, like other attributes

This is a rebase of rust-lang#83354, but without any language-changing parts ~(except for rust-lang#84110, i.e. the attribute expansion order is the same.

This is a pre-requisite for any other changes making cfg attributes closer to regular macro attributes
- Possibly changing their expansion order (rust-lang#83331)
- Keeping macro backtraces for cfg attributes, or otherwise making them visible after expansion without keeping them in place literally (rust-lang#84110).

Two exceptions to the "one by one" behavior are:
- cfgs eagerly expanded by `derive` and `cfg_eval`, they are still expanded in a batch, that's by design.
- cfgs at the crate root, they are currently expanded not during the main expansion pass, but before that, during `#![feature]` collection. I'll try to disentangle that logic later in a separate PR.

r? `@Aaron1011`
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) C-enhancement Category: An issue proposing an enhancement or a PR with one.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants