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

#[cfg_attr] #1242

Closed
DylanLukes opened this issue Dec 1, 2011 · 10 comments
Closed

#[cfg_attr] #1242

DylanLukes opened this issue Dec 1, 2011 · 10 comments
Labels
A-attributes Area: Attributes (`#[…]`, `#![…]`) A-frontend Area: Compiler frontend (errors, parsing and HIR) C-enhancement Category: An issue proposing an enhancement or a PR with one.
Milestone

Comments

@DylanLukes
Copy link

[cfg_attr] is a theoretical tag for conditional use of an attribute based on target.

For example:

#[cfg_attr(target_os="macos", foo, bar(a, b), ...)]
#[cfg_attr(target_os="linux", baz(c, d), qux, ...)]

On OS X this expands to

#[foo]
#[bar(a,b)]

On Linux is expands to

#[baz(c,d)]
#[bar]

This would probably be eventually replaced by a more powerful meta-item system. I'm thinking along the lines of cmake?

@DylanLukes
Copy link
Author

Btw, this is useful for linkage flags on native mods specifically.

@brson
Copy link
Contributor

brson commented Dec 2, 2011

It will also replace the #[ignore(cfg(...))] syntax with #[cfg_attr(..., ignore)]

@DylanLukes
Copy link
Author

What does #[ignore(cfg(...))] actually do?...

@brson
Copy link
Contributor

brson commented Dec 2, 2011

Marks a test as ignored when compiling with a matching configuration.

@DylanLukes
Copy link
Author

Thought about generalizing this. See here:

https://github.com/graydon/rust/wiki/Rust-Attributes-Preprocessing-Proposal

Maybe a new issue should be opened? I'll give it a shot and pull later anyhow.

@brson
Copy link
Contributor

brson commented Dec 14, 2011

Reopening because this is a useful idea independently of any possibly attribute overhaul, and much smaller in scope.

@boggle
Copy link
Contributor

boggle commented Dec 16, 2011

Beyond the concrete proposal I wonder how to access these in the compiler, config seems not very extensible. Ideally, one would be able to go from ast node to next enclosing ast node with an attached attribute but i dont see how to do this without a lot of extra book keeping.

(would like this for easier addition of compiler-level, pragma-like attributes)

@graydon
Copy link
Contributor

graydon commented Feb 15, 2012

I am warming to the more-general attribute processing proposal, given a little time spent working with attributes in production code. An interested party could make this work.

@DylanLukes
Copy link
Author

Well, I can try to throw together a demo interpreter for roughly what I'm thinking today to solidify how it could/should work.

My initial proposal has some issues I'd like to think out, and it'll need to be redone in many areas I think. For instance, predicates for use here could really be any pure predicate you could use in the typestate system.

@graydon
Copy link
Contributor

graydon commented Apr 5, 2012

I think this is now officially a dupe of #2119 and there's action there and none here, so closing this one.

@graydon graydon closed this as completed Apr 5, 2012
coastalwhite pushed a commit to coastalwhite/rust that referenced this issue Aug 5, 2023
celinval pushed a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
* Now gen-c display the c file instead of the goto binnary.

Co-authored-by: Jérôme Dubois <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-attributes Area: Attributes (`#[…]`, `#![…]`) A-frontend Area: Compiler frontend (errors, parsing and HIR) C-enhancement Category: An issue proposing an enhancement or a PR with one.
Projects
None yet
Development

No branches or pull requests

4 participants