summary refs log tree commit diff
path: root/src/libsyntax_ext/proc_macro_registrar.rs
AgeCommit message (Collapse)AuthorLines
2018-07-15Auto merge of #52383 - petrochenkov:pmns, r=alexcrichtonbors-5/+0
resolve: Functions introducing procedural macros reserve a slot in the macro namespace as well Similarly to https://github.com/rust-lang/rust/pull/52234, this gives us symmetry between internal and external views of a crate, but in this case it's always an error to call a procedural macro in the same crate in which it's defined. Closes https://github.com/rust-lang/rust/issues/52225
2018-07-14Auto merge of #52326 - alexcrichton:tweak-proc-macro-expand, r=petrochenkovbors-3/+8
rustc: Tweak expansion of #[proc_macro] for 2018 The syntactical expansion of `#[proc_macro]` and related attributes currently contains absolute paths which conflicts with a lint for the 2018 edition, causing issues like #52214. This commit puts a band-aid on the issue by ensuring that procedural macros can also migrate to the 2018 edition for now by tweaking the expansion based on what features are activated. A more long-term solution would probably tweak the edition hygiene of spans, but this should do the trick for now. Closes #52214
2018-07-14Functions introducing procedural macros reserve a slot in the macro ↵Vadim Petrochenkov-5/+0
namespace as well
2018-07-14Address commentsVadim Petrochenkov-6/+4
2018-07-14Remove most of `PartialEq` impls from AST and HIR structuresVadim Petrochenkov-5/+6
2018-07-13rustc: Tweak expansion of #[proc_macro] for 2018Alex Crichton-3/+8
The syntactical expansion of `#[proc_macro]` and related attributes currently contains absolute paths which conflicts with a lint for the 2018 edition, causing issues like #52214. This commit puts a band-aid on the issue by ensuring that procedural macros can also migrate to the 2018 edition for now by tweaking the expansion based on what features are activated. A more long-term solution would probably tweak the edition hygiene of spans, but this should do the trick for now. Closes #52214
2018-07-13proc_macro: Fix crate root detectionVadim Petrochenkov-10/+6
2018-07-12Rollup merge of #52295 - ljedrz:dyn_libsyntax_ext, r=petrochenkovkennytm-1/+1
Deny bare trait objects in src/libsyntax_ext Enforce `#![deny(bare_trait_objects)]` in `src/libsyntax_ext`.
2018-07-12Deny bare trait objects in src/libsyntax_extljedrz-1/+1
2018-07-11rustc: Verify #[proc_macro] is only a wordAlex Crichton-4/+4
... and perform the same verification for #[proc_macro_attribute], currently neither of these attributes take any arguments. Closes #52273
2018-06-27Implement `#[macro_export(local_inner_macros)]`Vadim Petrochenkov-0/+1
2018-06-23hygiene: Merge `NameAndSpan` into `ExpnInfo`Vadim Petrochenkov-8/+6
2018-05-17Add edition to expansion infoVadim Petrochenkov-1/+2
2018-04-06Use `Span::apply_mark` where possibleVadim Petrochenkov-2/+2
2018-02-18Change ast::Visibility to Spanned typeSeiichi Uchida-7/+7
2018-01-22Fix spurious warning on empty proc macro cratesRyan Cumming-1/+1
While attempting to reproduce rust-lang/rust#47086 I noticed the following warning: ```shell > rustc /dev/null --crate-type proc-macro warning: unused variable: `registrar` --> /dev/null:0:1 ``` As there are no macros to register the automatically generated registrar function for the crate has no body. As a result its `registrar` argument is unused triggering the above warning. The warning is confusing and not easily actionable by the developer. It could also be triggered legitimately by e.g. having all of the macros in a crate #[cfg]'ed out. Fix by naming the generated argument `_registrar` inside `mk_registrar()`. This suppresses the unused variable warning.
2017-12-28Prefer to use attr::contains_name() and attr::find_by_name()Seiichi Uchida-2/+2
2017-08-30Make fields of `Span` privateVadim Petrochenkov-1/+1
2017-08-15use field init shorthand EVERYWHEREZack M. Davis-4/+4
Like #43008 (f668999), but _much more aggressive_.
2017-08-12syntax: #[allow_internal_unsafe] bypasses the unsafe_code lint in macros.Eduard-Mihai Burtescu-0/+1
2017-05-25Hygienize `librustc_resolve`.Jeffrey Seyfried-1/+1
2017-05-12Pass crate attributes in visit.rsNick Cameron-1/+1
2017-03-29Merge `ExpnId` and `SyntaxContext`.Jeffrey Seyfried-2/+4
2017-03-14Refactor `Attribute` to use `Path` and `TokenStream` instead of `MetaItem`.Jeffrey Seyfried-6/+6
2017-03-10Refactor out `ast::ItemKind::MacroDef`.Jeffrey Seyfried-6/+10
2017-02-28Implement function-like procedural macros ( `#[proc_macro]`)Austin Bonander-9/+57
2017-02-05Rename CustomDerive to ProcMacroDerive for macros 1.1Josh Driver-4/+4
2017-01-16Implement `#[proc_macro_attribute]`Austin Bonander-69/+135
* Add support for `#[proc_macro]` * Reactivate `proc_macro` feature and gate `#[proc_macro_attribute]` under it * Have `#![feature(proc_macro)]` imply `#![feature(use_extern_macros)]`, error on legacy import of proc macros via `#[macro_use]`
2017-01-02rustc: Stabilize the `proc_macro` featureAlex Crichton-9/+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-15Require `#[proc_macro_derive]` functions to be `pub`.Jeffrey Seyfried-9/+10
2016-12-06annotate stricter lifetimes on LateLintPass methods to allow them to forward ↵Oliver Schneider-11/+14
to a Visitor
2016-12-02Allow --test to be used on proc-macro cratesJosh Driver-2/+4
2016-11-21Use `Symbol` instead of `InternedString` in the AST, HIR, and various other ↵Jeffrey Seyfried-2/+2
places.
2016-11-20Move `syntax::util::interner` -> `syntax::symbol`, cleanup.Jeffrey Seyfried-9/+9
2016-11-20Refactor `MetaItemKind` to use `Name`s instead of `InternedString`s.Jeffrey Seyfried-8/+7
2016-11-17Show a better error when using --test with #[proc_macro_derive]Josh Driver-0/+9
2016-11-09Rollup merge of #37614 - keeperofdakeys:proc_macro, r=jseyfriedEduard-Mihai Burtescu-15/+52
macros 1.1: Allow proc_macro functions to declare attributes to be mark as used This PR allows proc macro functions to declare attribute names that should be marked as used when attached to the deriving item. There are a few questions for this PR. - Currently this uses a separate attribute named `#[proc_macro_attributes(..)]`, is this the best choice? - In order to make this work, the `check_attribute` function had to be modified to not error on attributes marked as used. This is a pretty large change in semantics, is there a better way to do this? - I've got a few clones where I don't know if I need them (like turning `item` into a `TokenStream`), can these be avoided? - Is switching to `MultiItemDecorator` the right thing here? Also fixes https://github.com/rust-lang/rust/issues/37563.
2016-11-08Allow proc_macro functions to whitelist specific attributesJosh Driver-15/+52
By using a second attribute `attributes(Bar)` on proc_macro_derive, whitelist any attributes with the name `Bar` in the deriving item. This allows a proc_macro function to use custom attribtues without a custom attribute error or unused attribute lint.
2016-11-04Add error when proc_macro_derive is used not on functionsest31-0/+11
Fixes #37590
2016-10-29Move `CrateConfig` from `Crate` to `ParseSess`.Jeffrey Seyfried-1/+1
2016-10-06rustc: Rename rustc_macro to proc_macroAlex Crichton-0/+277
This commit blanket renames the `rustc_macro` infrastructure to `proc_macro`, which reflects the general consensus of #35900. A follow up PR to Cargo will be required to purge the `rustc-macro` name as well.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-12 03:31:13 +0000