summary refs log tree commit diff
path: root/src/libsyntax_ext/deriving/mod.rs
AgeCommit message (Collapse)AuthorLines
2016-09-26make emit_feature_err take a ParseSessTim Neumann-1/+1
2016-09-24Load macros from `#[macro_use]` extern crates in `resolve`.Jeffrey Seyfried-2/+2
2016-09-13Move macro resolution into `librustc_resolve`.Jeffrey Seyfried-7/+2
2016-09-07Avoid instaiblity errors in code generated by ↵Jeffrey Seyfried-1/+10
`syntax_ext::deriving::call_intrinsic()`.
2016-09-02rustc: Implement custom derive (macros 1.1)Alex Crichton-125/+171
This commit is an implementation of [RFC 1681] which adds support to the compiler for first-class user-define custom `#[derive]` modes with a far more stable API than plugins have today. [RFC 1681]: https://github.com/rust-lang/rfcs/blob/master/text/1681-macros-1.1.md The main features added by this commit are: * A new `rustc-macro` crate-type. This crate type represents one which will provide custom `derive` implementations and perhaps eventually flower into the implementation of macros 2.0 as well. * A new `rustc_macro` crate in the standard distribution. This crate will provide the runtime interface between macro crates and the compiler. The API here is particularly conservative right now but has quite a bit of room to expand into any manner of APIs required by macro authors. * The ability to load new derive modes through the `#[macro_use]` annotations on other crates. All support added here is gated behind the `rustc_macro` feature gate, both for the library support (the `rustc_macro` crate) as well as the language features. There are a few minor differences from the implementation outlined in the RFC, such as the `rustc_macro` crate being available as a dylib and all symbols are `dlsym`'d directly instead of having a shim compiled. These should only affect the implementation, however, not the public interface. This commit also ended up touching a lot of code related to `#[derive]`, making a few notable changes: * Recognized derive attributes are no longer desugared to `derive_Foo`. Wasn't sure how to keep this behavior and *not* expose it to custom derive. * Derive attributes no longer have access to unstable features by default, they have to opt in on a granular level. * The `derive(Copy,Clone)` optimization is now done through another "obscure attribute" which is just intended to ferry along in the compiler that such an optimization is possible. The `derive(PartialEq,Eq)` optimization was also updated to do something similar. --- One part of this PR which needs to be improved before stabilizing are the errors and exact interfaces here. The error messages are relatively poor quality and there are surprising spects of this such as `#[derive(PartialEq, Eq, MyTrait)]` not working by default. The custom attributes added by the compiler end up becoming unstable again when going through a custom impl. Hopefully though this is enough to start allowing experimentation on crates.io! syntax-[breaking-change]
2016-08-25Refactor away `AttrMetaMethods`.Jeffrey Seyfried-1/+0
2016-08-25Refactor away `AttrNestedMetaItemMethods`.Jeffrey Seyfried-1/+1
2016-08-25Implement RFC#1559: allow all literals in attributes.Sergio Benitez-3/+3
2016-08-12run rustfmt on libsyntax_ext folderSrinivas Reddy Thatiparthy-6/+6
2016-07-25General MetaItem encapsulation rewrites.cgswords-10/+9
2016-07-19Run rustfmt on libsyntax_ext/deriving folderSrinivas Reddy Thatiparthy-19/+23
2016-06-26Rollup merge of #34436 - jseyfried:no_block_expr, r=eddybJeffrey Seyfried-2/+1
To allow these braced macro invocation, this PR removes the optional expression from `ast::Block` and instead uses a `StmtKind::Expr` at the end of the statement list. Currently, braced macro invocations in blocks can expand into statements (and items) except when they are last in a block, in which case they can only expand into expressions. For example, ```rust macro_rules! make_stmt { () => { let x = 0; } } fn f() { make_stmt! {} //< This is OK... let x = 0; //< ... unless this line is commented out. } ``` Fixes #34418.
2016-06-23Remove field `expr` of `ast::Block`Jeffrey Seyfried-2/+1
2016-06-23Move errors from libsyntax to its own crateJonathan Turner-1/+2
2016-05-28Use the span of `#[derive_Eq]` for `#[structural_match]`Jeffrey Seyfried-42/+14
2016-05-28Fix spans of generated `#[derive_*]` attributesJeffrey Seyfried-31/+41
2016-05-02fix rebase flawsNiko Matsakis-3/+3
2016-04-22Remove the MacroVisitor pass.Leo Testard-30/+64
This pass was supposed to check use of gated features before `#[cfg]`-stripping but this was not the case since it in fact happens after. Checks that are actually important and must be done before macro expansion are now made where the features are actually used. Close #32648. Also ensure that attributes on macro-generated macro invocations are checked as well. Close #32782 and #32655.
2016-03-27deriving: factor out discriminant_value constructionAlex Burka-0/+17
2016-03-25check for both partialeq and eqNiko Matsakis-36/+45
2016-03-25modify #[deriving(Eq)] to emit #[structural_match]Niko Matsakis-2/+46
to careful use of the span from deriving, we can permit it in stable code if it derives from deriving (not-even-a-pun intended)
2016-03-14derive: improve hygiene for type parameters (see #2810)Alex Burka-4/+25
When deriving Hash, RustcEncodable and RustcDecodable, the syntax extension needs a type parameter to use in the inner method. They used to use __H, __S and __D respectively. If this conflicts with a type parameter already declared for the item, bad times result (see the test). There is no hygiene for type parameters, but this commit introduces a better heuristic by concatenating the names of all extant type parameters (and prepending __H).
2016-02-11[breaking-change] don't glob export ast::MetaItem_Oliver 'ker' Schneider-2/+2
2016-02-03remove dead #[derive(FromPrimitive)] codeAlex Burka-3/+0
2015-12-15Move built-in syntax extensions to a separate crateSeo Sanghyeon-0/+202