summary refs log tree commit diff
path: root/src/libsyntax_ext/deriving/mod.rs
AgeCommit message (Collapse)AuthorLines
2018-03-02Replace Rc with Lrc for shared dataJohn Kåre Alsaker-2/+2
2017-12-22Auto merge of #46732 - estebank:silence-recovered-blocks, r=petrochenkovbors-0/+1
Do not emit type errors on recovered blocks When a parse error occurs on a block, the parser will recover and create a block with the statements collected until that point. Now a flag stating that a recovery has been performed in this block is propagated so that the type checker knows that the type of the block (which will be identified as `()`) shouldn't be checked against the expectation to reduce the amount of irrelevant diagnostic errors shown to the user. Fix #44579.
2017-12-21Do not emit type errors on recovered blocksEsteban Küber-0/+1
When a parse error occurs on a block, the parser will recover and create a block with the statements collected until that point. Now a flag stating that a recovery has been performed in this block is propagated so that the type checker knows that the type of the block (which will be identified as `()`) shouldn't be checked against the expectation to reduce the amount of irrelevant diagnostic errors shown to the user.
2017-12-21Add GenericParam, refactor Generics in ast, hir, rustdocJonas Platte-4/+6
The Generics now contain one Vec of an enum for the generic parameters, rather than two separate Vec's for lifetime and type parameters. Additionally, places that previously used Vec<LifetimeDef> now use Vec<GenericParam> instead.
2017-12-09Use hygiene to access the injected crate (`core` or `std`) from builtin macros.Jeffrey Seyfried-23/+7
2017-08-30Make fields of `Span` privateVadim Petrochenkov-2/+2
2017-08-15use field init shorthand EVERYWHEREZack M. Davis-1/+1
Like #43008 (f668999), but _much more aggressive_.
2017-05-25Hygienize `librustc_resolve`.Jeffrey Seyfried-1/+1
2017-05-12Remove some unused macros from the rust codebaseest31-6/+0
Removes unused macros from: * libcore * libcollections The last use of these two macros was removed in commit b64c9d56700e2c41207166fe8709711ff02488ff when the char_range_at_reverse function was been removed. * librustc_errors Their last use was removed by commits 2f2c3e178325dc1837badcd7573c2c0905fab979 and 11dc974a38fd533aa692cea213305056cd3a6902. * libsyntax_ext * librustc_trans Also, put the otry macro in back/msvc/mod.rs under the same cfg argument as the places that use it.
2017-03-29Merge `ExpnId` and `SyntaxContext`.Jeffrey Seyfried-24/+10
2017-03-10Refactor out `ast::ItemKind::MacroDef`.Jeffrey Seyfried-1/+1
2017-02-05Move derive macro expansion into the MacroExpanderJosh Driver-238/+1
This removes the expand_derives function, and sprinkles the functionality throughout the Invocation Collector, Expander and Resolver.
2017-02-05Rename CustomDerive to ProcMacroDerive for macros 1.1Josh Driver-2/+2
2017-02-05Make builtin derives a SyntaxExtensionJosh Driver-21/+21
This allows builtin derives to be registered and resolved, just like other derive types.
2017-01-10Give custom derive spans an expansion IDNick Cameron-7/+20
2017-01-02rustc: Stabilize the `proc_macro` featureAlex Crichton-7/+1
This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the "Macros 1.1" feature of the language. Many more details can be found on the tracking issue, #35900. Closes #35900
2016-12-23Allow legacy custom derive authors to disable warnings in downstream crates.Jeffrey Seyfried-1/+3
2016-11-20Move `syntax::util::interner` -> `syntax::symbol`, cleanup.Jeffrey Seyfried-11/+11
2016-11-20Refactor `P<ast::MetaItem>` -> `ast::MetaItem`.Jeffrey Seyfried-1/+1
2016-11-20Refactor `MetaItemKind` to use `Name`s instead of `InternedString`s.Jeffrey Seyfried-30/+26
2016-11-20Refactor away `ast::Attribute_`.Jeffrey Seyfried-1/+1
2016-11-10Support `#[macro_reexport]`ing custom derives.Jeffrey Seyfried-2/+8
2016-10-31Changed most vec! invocations to use square bracesiirelu-2/+2
Most of the Rust community agrees that the vec! macro is clearer when called using square brackets [] instead of regular brackets (). Most of these ocurrences are from before macros allowed using different types of brackets. There is one left unchanged in a pretty-print test, as the pretty printer still wants it to have regular brackets.
2016-10-27deprecation message for custom deriveNick Cameron-1/+1
2016-10-27Deprecate custom_deriveNick Cameron-0/+1
Has a custom deprecation since deprecating features is not supported and is a pain to implement
2016-10-15Use the macro namespace for custom derives.Jeffrey Seyfried-7/+17
2016-10-10Expand `#[derive]` attribute macro invocations last.Jeffrey Seyfried-5/+30
2016-10-08Do not add an empty #[derive()] list in expand_derive (fixes #37033)Anthony Ramine-4/+6
2016-09-27rustc: Tweak expansion order of custom deriveAlex Crichton-94/+122
This commit alters the expansion order of custom macros-1.1 style `#[derive]` modes. Instead of left-to-right the expansion now happens in three categories, each of which is internally left-to-right: * Old-style custom derive (`#[derive_Foo]`) is expanded * New-style custom derive (macros 1.1) is expanded * Built in derive modes are expanded This gives built in derive modes maximal knowledge about the struct that's being expanded and also avoids pesky issues like exposing `#[structural_match]` or `#[rustc_copy_clone_marker]`. cc #35900
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)