Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.
Sign upcfg meta variables #831
Comments
alexcrichton
added
the
A-wishlist
label
Feb 11, 2015
This comment has been minimized.
This comment has been minimized.
|
Yeah this would be nice. This and bounds aliases from #804 should give us a more complete aliasing toolkit. |
This comment has been minimized.
This comment has been minimized.
|
If we expand macros within attributes, then this feature would drop out as a special case. For example: macro_rules! foo {
() => (any(super, long, clause))
}
#[cfg(foo!())] ...
#[cfg(not(foo!()))] ...Users wouldn't need to learn special syntax either -- just apply their existing macro knowledge. |
alexcrichton
referenced this issue
May 12, 2015
Closed
Allow defining new `cfg` values inside Rust #1114
lfairy
referenced this issue
Sep 12, 2015
Open
#[deriving(PartialEq, Eq, Show, Clone, Hash, PartialOrd, Ord, Default, Encodable, Decodable)] is too verbose #441
alexcrichton
referenced this issue
Nov 16, 2015
Merged
RFC: Improve Cargo target-specific dependencies #1361
petrochenkov
added
the
T-lang
label
Jan 29, 2018
petrochenkov
removed
the
A-wishlist
label
Feb 24, 2018
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
alexcrichton commentedFeb 11, 2015
It's quite often that a
cfgdirective in an attribute becomes fairy complicated when support for more platforms are added. Even worse, acfgblock is then often duplicated among many locations to configure off different items.The
thread_local/mod.rsfile is a good example of the amount of duplication.It would be nice to have something like the following
Here the clause
any(super, long, clause)would be shortened to the identifierfoowhich could then be used elsewhere. In general it would just be nice to make these longcfgdirectives much shorter and less error prone to copy-paste.