Skip to content
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

rustc: Process #[cfg]/#[cfg_attr] on crates #18634

Merged
merged 1 commit into from
Nov 8, 2014

Conversation

alexcrichton
Copy link
Member

This commit implements processing these two attributes at the crate level as
well as at the item level. When #[cfg] is applied at the crate level, then the
entire crate will be omitted if the cfg doesn't match. The #[cfg_attr] attribute
is processed as usual in that the attribute is included or not depending on
whether the cfg matches.

This was spurred on by motivations of #18585 where #[cfg_attr] annotations will
be applied at the crate-level.

cc #18585

@alexcrichton
Copy link
Member Author

r? @sfackler

"a crate cannot expand to more than one item");
let ast::Item {
attrs, span, node, ident: _, id: _, vis: _,
} = item.and_then(|x| x);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's up with this and_then?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The item has type P<T> and currently P<T> doesn't support moving out, but the and_then closure consumes the pointer and gets the contents by value, so I figured I'd take it out via that.

I could also just add .move() :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there any reason to not just use clone?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah this is trying to get the T out of the P<T>. This should ideally look like: let ast::Item { ... } = *item;

(match node {
ast::ItemMod(m) => m,
_ => panic!("fold converted a module to not a module"),
}, attrs, span)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The convention I tried to set for this (see fold.rs) is:

            item.and_then(|ast::Item { attrs, span, node, .. }| match node {
                ast::ItemMod(m) => (m, attrs, span),
                _ => panic!("fold converted a module to not a module"),
            })

@alexcrichton alexcrichton force-pushed the cfg-attr-crate-level branch 2 times, most recently from 269117b to efa0bee Compare November 7, 2014 02:12
bors added a commit that referenced this pull request Nov 7, 2014
…kler

This commit implements processing these two attributes at the crate level as
well as at the item level. When #[cfg] is applied at the crate level, then the
entire crate will be omitted if the cfg doesn't match. The #[cfg_attr] attribute
is processed as usual in that the attribute is included or not depending on
whether the cfg matches.

This was spurred on by motivations of #18585 where #[cfg_attr] annotations will
be applied at the crate-level.

cc #18585
This commit implements processing these two attributes at the crate level as
well as at the item level. When #[cfg] is applied at the crate level, then the
entire crate will be omitted if the cfg doesn't match. The #[cfg_attr] attribute
is processed as usual in that the attribute is included or not depending on
whether the cfg matches.

This was spurred on by motivations of rust-lang#18585 where #[cfg_attr] annotations will
be applied at the crate-level.

cc rust-lang#18585
bors added a commit that referenced this pull request Nov 8, 2014
…kler

This commit implements processing these two attributes at the crate level as
well as at the item level. When #[cfg] is applied at the crate level, then the
entire crate will be omitted if the cfg doesn't match. The #[cfg_attr] attribute
is processed as usual in that the attribute is included or not depending on
whether the cfg matches.

This was spurred on by motivations of #18585 where #[cfg_attr] annotations will
be applied at the crate-level.

cc #18585
@bors bors closed this Nov 8, 2014
@bors bors merged commit 3dbd328 into rust-lang:master Nov 8, 2014
@alexcrichton alexcrichton deleted the cfg-attr-crate-level branch November 20, 2014 03:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants