mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
rust/src/libsyntax/ext/base.rs

902 lines
30 KiB
Rust
Raw Normal View History

Add quasiquote for matchers and attributes
2015-02-24 19:56:01 +01:00
// Copyright 2015 The Rust Project Developers. See the COPYRIGHT
Update license, add license boilerplate to most files. Remainder will follow.
2012-12-03 16:48:01 -08:00
// file at the top-level directory of this distribution and at
// http://rust-lang.org/COPYRIGHT.
//
// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
// <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
// option. This file may not be copied, modified, or distributed
// except according to those terms.
Switch to purely namespaced enums This breaks code that referred to variant names in the same namespace as their enum. Reexport the variants in the old location or alter code to refer to the new locations: ``` pub enum Foo { A, B } fn main() { let a = A; } ``` => ``` pub use self::Foo::{A, B}; pub enum Foo { A, B } fn main() { let a = A; } ``` or ``` pub enum Foo { A, B } fn main() { let a = Foo::A; } ``` [breaking-change]
2014-11-06 00:05:53 -08:00
pub use self::SyntaxExtension::*;
librustc: Terminate name searches at the nearest module scope for paths that contain at least two components. r=graydon
2012-12-23 17:41:37 -05:00
use ast;
change to newer macro escape mechanism, using uints in more places
2013-05-08 15:27:29 -07:00
use ast::Name;
librustc: Terminate name searches at the nearest module scope for paths that contain at least two components. r=graydon
2012-12-23 17:41:37 -05:00
use codemap;
syntax: use an index in CodeMap instead of Gc for ExpnInfo.
2014-09-17 19:01:33 +03:00
use codemap::{CodeMap, Span, ExpnId, ExpnInfo, NO_EXPANSION};
librustc: Terminate name searches at the nearest module scope for paths that contain at least two components. r=graydon
2012-12-23 17:41:37 -05:00
use ext;
Implement a concat!() format extension This extension can be used to concatenate string literals at compile time. C has this useful ability when placing string literals lexically next to one another, but this needs to be handled at the syntax extension level to recursively expand macros. The major use case for this is something like: macro_rules! mylog( ($fmt:expr $($arg:tt)*) => { error2!(concat!(file!(), ":", line!(), " - ", $fmt) $($arg)*); }) Where the mylog macro will automatically prepend the filename/line number to the beginning of every log message.
2013-10-05 21:15:46 -07:00
use ext::expand;
Move #[macro_reexport] to extern crate
2015-01-01 16:37:47 -08:00
use ext::tt::macro_rules;
librustc: Terminate name searches at the nearest module scope for paths that contain at least two components. r=graydon
2012-12-23 17:41:37 -05:00
use parse;
Simplify creating a parser from a token tree Closes #15306
2014-07-03 11:42:24 +02:00
use parse::parser;
Removing unused imports
2013-03-26 16:38:07 -04:00
use parse::token;
librustc: Fix merge fallout.
2014-01-21 10:08:10 -08:00
use parse::token::{InternedString, intern, str_to_ident};
syntax: fix fallout from using ptr::P.
2014-09-13 19:06:01 +03:00
use ptr::P;
Support multiple item macros Closes #4375
2013-11-24 23:08:53 -08:00
use util::small_vector::SmallVector;
move RenameList to mtwt, add new_renames abstraction
2014-07-02 22:38:30 -07:00
use ext::mtwt;
Refactoring: Only use `MacroExpander` for expanding outside of `syntax::ext::expand`
2014-07-20 16:25:35 +02:00
use fold::Folder;
librustc: Terminate name searches at the nearest module scope for paths that contain at least two components. r=graydon
2012-12-23 17:41:37 -05:00
Fallout from the libcollections movement
2014-05-29 19:03:06 -07:00
use std::collections::HashMap;
Moved `syntax::ext::base::SyntaxEnv` into `syntax::ext::base::ExtCtx`
2014-07-19 21:34:24 +02:00
use std::rc::Rc;
Replace MacExpr / MacPat / MacItems with MacEager MacEager is a MacResult implementation for the common case where you've already built each form of AST that you might return. Fixes #17637. Based on #18814. This is a [breaking-change] for syntax extensions: * MacExpr::new becomes MacEager::expr. * MacPat::new becomes MacEager::pat. * MacItems::new becomes MacEager::items. It takes a SmallVector directly, not an iterator.
2015-02-27 11:14:42 -08:00
use std::default::Default;
rustc: Introduce ext module. Move some things from parser to ext. Introduce an ext_ctxt record to provide a span_err method for use while expanding syntax extensions. Hopefully it will be useful for other things.
2011-06-04 15:41:45 -04:00
Change ItemModifier and ItemDecorator to traits For convenience, the traits are implemented for the respective bare functions. Change code from this: ```rust ItemDecorator(some_function) // or ItemModifier(some_other_function) ``` to ```rust ItemDecorator(box some_function) // or ItemModifier(box some_other_function) ``` [breaking-change]
2014-09-09 23:57:14 -07:00
pub trait ItemDecorator {
fn expand(&self,
ecx: &mut ExtCtxt,
sp: Span,
syntax: fix fallout from using ptr::P.
2014-09-13 19:06:01 +03:00
meta_item: &ast::MetaItem,
item: &ast::Item,
Fix fallout in libsyntax from RFC 599. Clarity and efficiency seems to be mostly improved, to my eye. Nonetheless, as this commit demonstrates, the previous commits was a [breaking-change]. In practice, breakage is focused on functions of this form: ```rust fn foo(..., object: Box<FnMut()>) ```` where `FnMut()` could be any trait object type. The older scheme defaulted objects in argument position so that they were bounded by a fresh lifetime: ```rust fn foo<'a>(..., object: Box<FnMut()+'a>) ``` This meant that the object could contain borrowed data. The newer scheme defaults to a lifetime bound of `'static`: ```rust fn foo(..., object: Box<FnMut()+'static>) ``` This means that the object cannot contain borrowed data. In some cases, the best fix is to stop using `Box`: ```rust fn foo(..., object: &mut FnMut()) ``` but another option is to write an explicit annotation for the `'a` lifetime that used to be implicit. Both fixes are demonstrated in this commit.
2015-02-12 10:41:47 -05:00
push: &mut FnMut(P<ast::Item>));
Change ItemModifier and ItemDecorator to traits For convenience, the traits are implemented for the respective bare functions. Change code from this: ```rust ItemDecorator(some_function) // or ItemModifier(some_other_function) ``` to ```rust ItemDecorator(box some_function) // or ItemModifier(box some_other_function) ``` [breaking-change]
2014-09-09 23:57:14 -07:00
}
Fix fallout from changes. In cases where stage0 compiler is needed, we cannot use an `as` expression to coerce, so I used a one-off function instead (this is a no-op in stage0, but in stage1+ it triggers coercion from the fn pointer to the fn item type).
2014-11-26 05:52:16 -05:00
impl<F> ItemDecorator for F
Fix fallout in libsyntax from RFC 599. Clarity and efficiency seems to be mostly improved, to my eye. Nonetheless, as this commit demonstrates, the previous commits was a [breaking-change]. In practice, breakage is focused on functions of this form: ```rust fn foo(..., object: Box<FnMut()>) ```` where `FnMut()` could be any trait object type. The older scheme defaulted objects in argument position so that they were bounded by a fresh lifetime: ```rust fn foo<'a>(..., object: Box<FnMut()+'a>) ``` This meant that the object could contain borrowed data. The newer scheme defaults to a lifetime bound of `'static`: ```rust fn foo(..., object: Box<FnMut()+'static>) ``` This means that the object cannot contain borrowed data. In some cases, the best fix is to stop using `Box`: ```rust fn foo(..., object: &mut FnMut()) ``` but another option is to write an explicit annotation for the `'a` lifetime that used to be implicit. Both fixes are demonstrated in this commit.
2015-02-12 10:41:47 -05:00
where F : Fn(&mut ExtCtxt, Span, &ast::MetaItem, &ast::Item, &mut FnMut(P<ast::Item>))
Fix fallout from changes. In cases where stage0 compiler is needed, we cannot use an `as` expression to coerce, so I used a one-off function instead (this is a no-op in stage0, but in stage1+ it triggers coercion from the fn pointer to the fn item type).
2014-11-26 05:52:16 -05:00
{
Change ItemModifier and ItemDecorator to traits For convenience, the traits are implemented for the respective bare functions. Change code from this: ```rust ItemDecorator(some_function) // or ItemModifier(some_other_function) ``` to ```rust ItemDecorator(box some_function) // or ItemModifier(box some_other_function) ``` [breaking-change]
2014-09-09 23:57:14 -07:00
fn expand(&self,
ecx: &mut ExtCtxt,
sp: Span,
syntax: fix fallout from using ptr::P.
2014-09-13 19:06:01 +03:00
meta_item: &ast::MetaItem,
item: &ast::Item,
Fix fallout in libsyntax from RFC 599. Clarity and efficiency seems to be mostly improved, to my eye. Nonetheless, as this commit demonstrates, the previous commits was a [breaking-change]. In practice, breakage is focused on functions of this form: ```rust fn foo(..., object: Box<FnMut()>) ```` where `FnMut()` could be any trait object type. The older scheme defaulted objects in argument position so that they were bounded by a fresh lifetime: ```rust fn foo<'a>(..., object: Box<FnMut()+'a>) ``` This meant that the object could contain borrowed data. The newer scheme defaults to a lifetime bound of `'static`: ```rust fn foo(..., object: Box<FnMut()+'static>) ``` This means that the object cannot contain borrowed data. In some cases, the best fix is to stop using `Box`: ```rust fn foo(..., object: &mut FnMut()) ``` but another option is to write an explicit annotation for the `'a` lifetime that used to be implicit. Both fixes are demonstrated in this commit.
2015-02-12 10:41:47 -05:00
push: &mut FnMut(P<ast::Item>)) {
Fix fallout from changes. In cases where stage0 compiler is needed, we cannot use an `as` expression to coerce, so I used a one-off function instead (this is a no-op in stage0, but in stage1+ it triggers coercion from the fn pointer to the fn item type).
2014-11-26 05:52:16 -05:00
(*self)(ecx, sp, meta_item, item, push)
Change ItemModifier and ItemDecorator to traits For convenience, the traits are implemented for the respective bare functions. Change code from this: ```rust ItemDecorator(some_function) // or ItemModifier(some_other_function) ``` to ```rust ItemDecorator(box some_function) // or ItemModifier(box some_other_function) ``` [breaking-change]
2014-09-09 23:57:14 -07:00
}
}
Enable item macros to define macros.
2012-07-06 14:29:50 -07:00
Change ItemModifier and ItemDecorator to traits For convenience, the traits are implemented for the respective bare functions. Change code from this: ```rust ItemDecorator(some_function) // or ItemModifier(some_other_function) ``` to ```rust ItemDecorator(box some_function) // or ItemModifier(box some_other_function) ``` [breaking-change]
2014-09-09 23:57:14 -07:00
pub trait ItemModifier {
fn expand(&self,
ecx: &mut ExtCtxt,
span: Span,
syntax: fix fallout from using ptr::P.
2014-09-13 19:06:01 +03:00
meta_item: &ast::MetaItem,
item: P<ast::Item>)
-> P<ast::Item>;
Change ItemModifier and ItemDecorator to traits For convenience, the traits are implemented for the respective bare functions. Change code from this: ```rust ItemDecorator(some_function) // or ItemModifier(some_other_function) ``` to ```rust ItemDecorator(box some_function) // or ItemModifier(box some_other_function) ``` [breaking-change]
2014-09-09 23:57:14 -07:00
}
Fix fallout from changes. In cases where stage0 compiler is needed, we cannot use an `as` expression to coerce, so I used a one-off function instead (this is a no-op in stage0, but in stage1+ it triggers coercion from the fn pointer to the fn item type).
2014-11-26 05:52:16 -05:00
impl<F> ItemModifier for F
where F : Fn(&mut ExtCtxt, Span, &ast::MetaItem, P<ast::Item>) -> P<ast::Item>
{
Change ItemModifier and ItemDecorator to traits For convenience, the traits are implemented for the respective bare functions. Change code from this: ```rust ItemDecorator(some_function) // or ItemModifier(some_other_function) ``` to ```rust ItemDecorator(box some_function) // or ItemModifier(box some_other_function) ``` [breaking-change]
2014-09-09 23:57:14 -07:00
fn expand(&self,
ecx: &mut ExtCtxt,
span: Span,
syntax: fix fallout from using ptr::P.
2014-09-13 19:06:01 +03:00
meta_item: &ast::MetaItem,
item: P<ast::Item>)
-> P<ast::Item> {
Fix fallout from changes. In cases where stage0 compiler is needed, we cannot use an `as` expression to coerce, so I used a one-off function instead (this is a no-op in stage0, but in stage1+ it triggers coercion from the fn pointer to the fn item type).
2014-11-26 05:52:16 -05:00
(*self)(ecx, span, meta_item, item)
Change ItemModifier and ItemDecorator to traits For convenience, the traits are implemented for the respective bare functions. Change code from this: ```rust ItemDecorator(some_function) // or ItemModifier(some_other_function) ``` to ```rust ItemDecorator(box some_function) // or ItemModifier(box some_other_function) ``` [breaking-change]
2014-09-09 23:57:14 -07:00
}
}
Add an ItemModifier syntax extension type Where ItemDecorator creates new items given a single item, ItemModifier alters the tagged item in place. The expansion rules for this are a bit weird, but I think are the most reasonable option available. When an item is expanded, all ItemModifier attributes are stripped from it and the item is folded through all ItemModifiers. At that point, the process repeats until there are no ItemModifiers in the new item.
2014-02-27 23:49:25 -08:00
s/Show/Debug/g
2015-01-28 08:34:18 -05:00
#[derive(Debug,Clone)]
Syntax extensions on trait and impl items. Allows modifiers to be used on methods, associated types, etc.
2014-12-02 10:07:41 -08:00
pub enum Annotatable {
Item(P<ast::Item>),
syntax: gather common fields of impl & trait items into their respective types.
2015-03-10 12:28:44 +02:00
TraitItem(P<ast::TraitItem>),
ImplItem(P<ast::ImplItem>),
Syntax extensions on trait and impl items. Allows modifiers to be used on methods, associated types, etc.
2014-12-02 10:07:41 -08:00
}
impl Annotatable {
pub fn attrs(&self) -> &[ast::Attribute] {
match *self {
Remove remaining uses of `[]`. This time I tried to use deref coercions where possible.
2015-02-20 14:08:14 -05:00
Annotatable::Item(ref i) => &i.attrs,
syntax: gather common fields of impl & trait items into their respective types.
2015-03-10 12:28:44 +02:00
Annotatable::TraitItem(ref ti) => &ti.attrs,
Annotatable::ImplItem(ref ii) => &ii.attrs,
Syntax extensions on trait and impl items. Allows modifiers to be used on methods, associated types, etc.
2014-12-02 10:07:41 -08:00
}
}
pub fn fold_attrs(self, attrs: Vec<ast::Attribute>) -> Annotatable {
match self {
syntax: move indirection around {Trait,Impl}Item, from within.
2015-03-05 04:48:54 +02:00
Annotatable::Item(i) => Annotatable::Item(i.map(|i| ast::Item {
Syntax extensions on trait and impl items. Allows modifiers to be used on methods, associated types, etc.
2014-12-02 10:07:41 -08:00
attrs: attrs,
syntax: move indirection around {Trait,Impl}Item, from within.
2015-03-05 04:48:54 +02:00
..i
Syntax extensions on trait and impl items. Allows modifiers to be used on methods, associated types, etc.
2014-12-02 10:07:41 -08:00
})),
syntax: gather common fields of impl & trait items into their respective types.
2015-03-10 12:28:44 +02:00
Annotatable::TraitItem(i) => Annotatable::TraitItem(i.map(|ti| {
ast::TraitItem { attrs: attrs, ..ti }
})),
Annotatable::ImplItem(i) => Annotatable::ImplItem(i.map(|ii| {
ast::ImplItem { attrs: attrs, ..ii }
})),
Syntax extensions on trait and impl items. Allows modifiers to be used on methods, associated types, etc.
2014-12-02 10:07:41 -08:00
}
}
pub fn expect_item(self) -> P<ast::Item> {
match self {
Annotatable::Item(i) => i,
_ => panic!("expected Item")
}
}
syntax: gather common fields of impl & trait items into their respective types.
2015-03-10 12:28:44 +02:00
pub fn expect_trait_item(self) -> P<ast::TraitItem> {
Syntax extensions on trait and impl items. Allows modifiers to be used on methods, associated types, etc.
2014-12-02 10:07:41 -08:00
match self {
Annotatable::TraitItem(i) => i,
_ => panic!("expected Item")
}
}
syntax: gather common fields of impl & trait items into their respective types.
2015-03-10 12:28:44 +02:00
pub fn expect_impl_item(self) -> P<ast::ImplItem> {
Syntax extensions on trait and impl items. Allows modifiers to be used on methods, associated types, etc.
2014-12-02 10:07:41 -08:00
match self {
Annotatable::ImplItem(i) => i,
_ => panic!("expected Item")
}
}
}
// A more flexible ItemModifier (ItemModifier should go away, eventually, FIXME).
// meta_item is the annotation, item is the item being modified, parent_item
// is the impl or trait item is declared in if item is part of such a thing.
// FIXME Decorators should follow the same pattern too.
pub trait MultiItemModifier {
fn expand(&self,
ecx: &mut ExtCtxt,
span: Span,
meta_item: &ast::MetaItem,
item: Annotatable)
-> Annotatable;
}
impl<F> MultiItemModifier for F
where F: Fn(&mut ExtCtxt,
Span,
&ast::MetaItem,
Annotatable) -> Annotatable
{
fn expand(&self,
ecx: &mut ExtCtxt,
span: Span,
meta_item: &ast::MetaItem,
item: Annotatable)
-> Annotatable {
(*self)(ecx, span, meta_item, item)
}
}
rename one of the two confusing MacroExpanders There were two things named MacroExpander, which was confusing. I renamed one of them TTMacroExpander. [breaking change]
2014-07-10 12:09:56 -07:00
/// Represents a thing that maps token trees to Macro Results
pub trait TTMacroExpander {
Implement generalized object and type parameter bounds (Fixes #16462)
2014-08-27 21:46:52 -04:00
fn expand<'cx>(&self,
ecx: &'cx mut ExtCtxt,
span: Span,
token_tree: &[ast::TokenTree])
-> Box<MacResult+'cx>;
libsyntax: Remove some more `@fn`s from the macro expander
2013-08-30 14:40:05 -07:00
}
Simplify and rename macro API Now that procedural macros can be implemented outside of the compiler, it's more important to have a reasonable API to work with. Here are the basic changes: * Rename SyntaxExpanderTTTrait to MacroExpander, SyntaxExpanderTT to BasicMacroExpander, etc. I think "procedural macro" is the right term for these now, right? The other option would be SynExtExpander or something like that. * Stop passing the SyntaxContext to extensions. This was only ever used by macro_rules, which doesn't even use it anymore. I can't think of a context in which an external extension would need it, and removal allows the API to be significantly simpler - no more SyntaxExpanderTTItemExpanderWithoutContext wrappers to worry about.
2014-01-25 13:34:26 -08:00
pub type MacroExpanderFn =
fix "warning: deprecated syntax, use `for` keyword now"
2014-11-13 08:59:44 -05:00
for<'cx> fn(&'cx mut ExtCtxt, Span, &[ast::TokenTree]) -> Box<MacResult+'cx>;
libsyntax: Remove some more `@fn`s from the macro expander
2013-08-30 14:40:05 -07:00
Fix fallout from changes. In cases where stage0 compiler is needed, we cannot use an `as` expression to coerce, so I used a one-off function instead (this is a no-op in stage0, but in stage1+ it triggers coercion from the fn pointer to the fn item type).
2014-11-26 05:52:16 -05:00
impl<F> TTMacroExpander for F
where F : for<'cx> Fn(&'cx mut ExtCtxt, Span, &[ast::TokenTree]) -> Box<MacResult+'cx>
{
Implement generalized object and type parameter bounds (Fixes #16462)
2014-08-27 21:46:52 -04:00
fn expand<'cx>(&self,
ecx: &'cx mut ExtCtxt,
span: Span,
token_tree: &[ast::TokenTree])
-> Box<MacResult+'cx> {
Fix fallout from changes. In cases where stage0 compiler is needed, we cannot use an `as` expression to coerce, so I used a one-off function instead (this is a no-op in stage0, but in stage1+ it triggers coercion from the fn pointer to the fn item type).
2014-11-26 05:52:16 -05:00
(*self)(ecx, span, token_tree)
libsyntax: Remove some more `@fn`s from the macro expander
2013-08-30 14:40:05 -07:00
}
}
capturing macros now implemented
2013-07-08 15:55:14 -07:00
Simplify and rename macro API Now that procedural macros can be implemented outside of the compiler, it's more important to have a reasonable API to work with. Here are the basic changes: * Rename SyntaxExpanderTTTrait to MacroExpander, SyntaxExpanderTT to BasicMacroExpander, etc. I think "procedural macro" is the right term for these now, right? The other option would be SynExtExpander or something like that. * Stop passing the SyntaxContext to extensions. This was only ever used by macro_rules, which doesn't even use it anymore. I can't think of a context in which an external extension would need it, and removal allows the API to be significantly simpler - no more SyntaxExpanderTTItemExpanderWithoutContext wrappers to worry about.
2014-01-25 13:34:26 -08:00
pub trait IdentMacroExpander {
Implement generalized object and type parameter bounds (Fixes #16462)
2014-08-27 21:46:52 -04:00
fn expand<'cx>(&self,
cx: &'cx mut ExtCtxt,
sp: Span,
ident: ast::Ident,
token_tree: Vec<ast::TokenTree> )
-> Box<MacResult+'cx>;
libsyntax: Remove some more `@fn`s from the macro expander
2013-08-30 14:40:05 -07:00
}
Remove BasicMacroExpander and BasicIdentMacroExpander The spans inside of these types were always None and never used. Pass the expander function directly instead of wrapping it in one of these types. [breaking-change]
2014-09-10 20:59:26 -07:00
pub type IdentMacroExpanderFn =
fix "warning: deprecated syntax, use `for` keyword now"
2014-11-13 08:59:44 -05:00
for<'cx> fn(&'cx mut ExtCtxt, Span, ast::Ident, Vec<ast::TokenTree>) -> Box<MacResult+'cx>;
Remove BasicMacroExpander and BasicIdentMacroExpander The spans inside of these types were always None and never used. Pass the expander function directly instead of wrapping it in one of these types. [breaking-change]
2014-09-10 20:59:26 -07:00
Fix fallout from changes. In cases where stage0 compiler is needed, we cannot use an `as` expression to coerce, so I used a one-off function instead (this is a no-op in stage0, but in stage1+ it triggers coercion from the fn pointer to the fn item type).
2014-11-26 05:52:16 -05:00
impl<F> IdentMacroExpander for F
where F : for<'cx> Fn(&'cx mut ExtCtxt, Span, ast::Ident,
Vec<ast::TokenTree>) -> Box<MacResult+'cx>
{
Implement generalized object and type parameter bounds (Fixes #16462)
2014-08-27 21:46:52 -04:00
fn expand<'cx>(&self,
cx: &'cx mut ExtCtxt,
sp: Span,
ident: ast::Ident,
token_tree: Vec<ast::TokenTree> )
Fix fallout from changes. In cases where stage0 compiler is needed, we cannot use an `as` expression to coerce, so I used a one-off function instead (this is a no-op in stage0, but in stage1+ it triggers coercion from the fn pointer to the fn item type).
2014-11-26 05:52:16 -05:00
-> Box<MacResult+'cx>
{
(*self)(cx, sp, ident, token_tree)
libsyntax: Remove some more `@fn`s from the macro expander
2013-08-30 14:40:05 -07:00
}
}
Replace MacExpr / MacPat / MacItems with MacEager MacEager is a MacResult implementation for the common case where you've already built each form of AST that you might return. Fixes #17637. Based on #18814. This is a [breaking-change] for syntax extensions: * MacExpr::new becomes MacEager::expr. * MacPat::new becomes MacEager::pat. * MacItems::new becomes MacEager::items. It takes a SmallVector directly, not an iterator.
2015-02-27 11:14:42 -08:00
// Use a macro because forwarding to a simple function has type system issues
macro_rules! make_stmt_default {
($me:expr) => {
$me.make_expr().map(|e| {
P(codemap::respan(e.span, ast::StmtExpr(e, ast::DUMMY_NODE_ID)))
})
}
}
syntax: unify all MacResult's into a single trait. There's now one unified way to return things from a macro, instead of being able to choose the `AnyMacro` trait or the `MRItem`/`MRExpr` variants of the `MacResult` enum. This does simplify the logic handling the expansions, but the biggest value of this is it makes macros in (for example) type position easier to implement, as there's this single thing to modify. By my measurements (using `-Z time-passes` on libstd and librustc etc.), this appears to have little-to-no impact on expansion speed. There are presumably larger costs than the small number of extra allocations and virtual calls this adds (notably, all `macro_rules!`-defined macros have not changed in behaviour, since they had to use the `AnyMacro` trait anyway).
2014-04-15 22:00:14 +10:00
/// The result of a macro expansion. The return values of the various
Replace MacExpr / MacPat / MacItems with MacEager MacEager is a MacResult implementation for the common case where you've already built each form of AST that you might return. Fixes #17637. Based on #18814. This is a [breaking-change] for syntax extensions: * MacExpr::new becomes MacEager::expr. * MacPat::new becomes MacEager::pat. * MacItems::new becomes MacEager::items. It takes a SmallVector directly, not an iterator.
2015-02-27 11:14:42 -08:00
/// methods are spliced into the AST at the callsite of the macro.
syntax: unify all MacResult's into a single trait. There's now one unified way to return things from a macro, instead of being able to choose the `AnyMacro` trait or the `MRItem`/`MRExpr` variants of the `MacResult` enum. This does simplify the logic handling the expansions, but the biggest value of this is it makes macros in (for example) type position easier to implement, as there's this single thing to modify. By my measurements (using `-Z time-passes` on libstd and librustc etc.), this appears to have little-to-no impact on expansion speed. There are presumably larger costs than the small number of extra allocations and virtual calls this adds (notably, all `macro_rules!`-defined macros have not changed in behaviour, since they had to use the `AnyMacro` trait anyway).
2014-04-15 22:00:14 +10:00
pub trait MacResult {
/// Create an expression.
syntax: fix fallout from using ptr::P.
2014-09-13 19:06:01 +03:00
fn make_expr(self: Box<Self>) -> Option<P<ast::Expr>> {
syntax: unify all MacResult's into a single trait. There's now one unified way to return things from a macro, instead of being able to choose the `AnyMacro` trait or the `MRItem`/`MRExpr` variants of the `MacResult` enum. This does simplify the logic handling the expansions, but the biggest value of this is it makes macros in (for example) type position easier to implement, as there's this single thing to modify. By my measurements (using `-Z time-passes` on libstd and librustc etc.), this appears to have little-to-no impact on expansion speed. There are presumably larger costs than the small number of extra allocations and virtual calls this adds (notably, all `macro_rules!`-defined macros have not changed in behaviour, since they had to use the `AnyMacro` trait anyway).
2014-04-15 22:00:14 +10:00
None
}
/// Create zero or more items.
syntax: fix fallout from using ptr::P.
2014-09-13 19:06:01 +03:00
fn make_items(self: Box<Self>) -> Option<SmallVector<P<ast::Item>>> {
syntax: unify all MacResult's into a single trait. There's now one unified way to return things from a macro, instead of being able to choose the `AnyMacro` trait or the `MRItem`/`MRExpr` variants of the `MacResult` enum. This does simplify the logic handling the expansions, but the biggest value of this is it makes macros in (for example) type position easier to implement, as there's this single thing to modify. By my measurements (using `-Z time-passes` on libstd and librustc etc.), this appears to have little-to-no impact on expansion speed. There are presumably larger costs than the small number of extra allocations and virtual calls this adds (notably, all `macro_rules!`-defined macros have not changed in behaviour, since they had to use the `AnyMacro` trait anyway).
2014-04-15 22:00:14 +10:00
None
}
add make_method method to MacResult trait this allows macro results to be parsed as methods
2014-07-10 17:46:09 -07:00
syntax: move MethMac to MacImplItem and combine {Provided,Required}Method into MethodTraitItem.
2015-03-11 23:38:58 +02:00
/// Create zero or more impl items.
fn make_impl_items(self: Box<Self>) -> Option<SmallVector<P<ast::ImplItem>>> {
add make_method method to MacResult trait this allows macro results to be parsed as methods
2014-07-10 17:46:09 -07:00
None
}
Add patterns to MacResult
2014-05-19 13:32:51 -07:00
/// Create a pattern.
syntax: fix fallout from using ptr::P.
2014-09-13 19:06:01 +03:00
fn make_pat(self: Box<Self>) -> Option<P<ast::Pat>> {
Add patterns to MacResult
2014-05-19 13:32:51 -07:00
None
}
syntax: unify all MacResult's into a single trait. There's now one unified way to return things from a macro, instead of being able to choose the `AnyMacro` trait or the `MRItem`/`MRExpr` variants of the `MacResult` enum. This does simplify the logic handling the expansions, but the biggest value of this is it makes macros in (for example) type position easier to implement, as there's this single thing to modify. By my measurements (using `-Z time-passes` on libstd and librustc etc.), this appears to have little-to-no impact on expansion speed. There are presumably larger costs than the small number of extra allocations and virtual calls this adds (notably, all `macro_rules!`-defined macros have not changed in behaviour, since they had to use the `AnyMacro` trait anyway).
2014-04-15 22:00:14 +10:00
/// Create a statement.
///
/// By default this attempts to create an expression statement,
/// returning None if that fails.
syntax: fix fallout from using ptr::P.
2014-09-13 19:06:01 +03:00
fn make_stmt(self: Box<Self>) -> Option<P<ast::Stmt>> {
Replace MacExpr / MacPat / MacItems with MacEager MacEager is a MacResult implementation for the common case where you've already built each form of AST that you might return. Fixes #17637. Based on #18814. This is a [breaking-change] for syntax extensions: * MacExpr::new becomes MacEager::expr. * MacPat::new becomes MacEager::pat. * MacItems::new becomes MacEager::items. It takes a SmallVector directly, not an iterator.
2015-02-27 11:14:42 -08:00
make_stmt_default!(self)
syntax: unify all MacResult's into a single trait. There's now one unified way to return things from a macro, instead of being able to choose the `AnyMacro` trait or the `MRItem`/`MRExpr` variants of the `MacResult` enum. This does simplify the logic handling the expansions, but the biggest value of this is it makes macros in (for example) type position easier to implement, as there's this single thing to modify. By my measurements (using `-Z time-passes` on libstd and librustc etc.), this appears to have little-to-no impact on expansion speed. There are presumably larger costs than the small number of extra allocations and virtual calls this adds (notably, all `macro_rules!`-defined macros have not changed in behaviour, since they had to use the `AnyMacro` trait anyway).
2014-04-15 22:00:14 +10:00
}
libsyntax: Remove some more `@fn`s from the macro expander
2013-08-30 14:40:05 -07:00
}
capturing macros now implemented
2013-07-08 15:55:14 -07:00
Replace MacExpr / MacPat / MacItems with MacEager MacEager is a MacResult implementation for the common case where you've already built each form of AST that you might return. Fixes #17637. Based on #18814. This is a [breaking-change] for syntax extensions: * MacExpr::new becomes MacEager::expr. * MacPat::new becomes MacEager::pat. * MacItems::new becomes MacEager::items. It takes a SmallVector directly, not an iterator.
2015-02-27 11:14:42 -08:00
macro_rules! make_MacEager {
( $( $fld:ident: $t:ty, )* ) => {
/// `MacResult` implementation for the common case where you've already
/// built each form of AST that you might return.
#[derive(Default)]
pub struct MacEager {
$(
pub $fld: Option<$t>,
)*
}
impl MacEager {
$(
pub fn $fld(v: $t) -> Box<MacResult> {
box MacEager {
$fld: Some(v),
..Default::default()
Add trivial cast lints. This permits all coercions to be performed in casts, but adds lints to warn in those cases. Part of this patch moves cast checking to a later stage of type checking. We acquire obligations to check casts as part of type checking where we previously checked them. Once we have type checked a function or module, then we check any cast obligations which have been acquired. That means we have more type information available to check casts (this was crucial to making coercions work properly in place of some casts), but it means that casts cannot feed input into type inference. [breaking change] * Adds two new lints for trivial casts and trivial numeric casts, these are warn by default, but can cause errors if you build with warnings as errors. Previously, trivial numeric casts and casts to trait objects were allowed. * The unused casts lint has gone. * Interactions between casting and type inference have changed in subtle ways. Two ways this might manifest are: - You may need to 'direct' casts more with extra type information, for example, in some cases where `foo as _ as T` succeeded, you may now need to specify the type for `_` - Casts do not influence inference of integer types. E.g., the following used to type check: ``` let x = 42; let y = &x as *const u32; ``` Because the cast would inform inference that `x` must have type `u32`. This no longer applies and the compiler will fallback to `i32` for `x` and thus there will be a type error in the cast. The solution is to add more type information: ``` let x: u32 = 42; let y = &x as *const u32; ```
2015-03-20 17:15:27 +13:00
}
Replace MacExpr / MacPat / MacItems with MacEager MacEager is a MacResult implementation for the common case where you've already built each form of AST that you might return. Fixes #17637. Based on #18814. This is a [breaking-change] for syntax extensions: * MacExpr::new becomes MacEager::expr. * MacPat::new becomes MacEager::pat. * MacItems::new becomes MacEager::items. It takes a SmallVector directly, not an iterator.
2015-02-27 11:14:42 -08:00
}
)*
Allow ExprLit expression macros to be used in patterns.
2014-08-31 01:45:11 +03:00
}
}
syntax: unify all MacResult's into a single trait. There's now one unified way to return things from a macro, instead of being able to choose the `AnyMacro` trait or the `MRItem`/`MRExpr` variants of the `MacResult` enum. This does simplify the logic handling the expansions, but the biggest value of this is it makes macros in (for example) type position easier to implement, as there's this single thing to modify. By my measurements (using `-Z time-passes` on libstd and librustc etc.), this appears to have little-to-no impact on expansion speed. There are presumably larger costs than the small number of extra allocations and virtual calls this adds (notably, all `macro_rules!`-defined macros have not changed in behaviour, since they had to use the `AnyMacro` trait anyway).
2014-04-15 22:00:14 +10:00
}
Replace MacExpr / MacPat / MacItems with MacEager MacEager is a MacResult implementation for the common case where you've already built each form of AST that you might return. Fixes #17637. Based on #18814. This is a [breaking-change] for syntax extensions: * MacExpr::new becomes MacEager::expr. * MacPat::new becomes MacEager::pat. * MacItems::new becomes MacEager::items. It takes a SmallVector directly, not an iterator.
2015-02-27 11:14:42 -08:00
make_MacEager! {
expr: P<ast::Expr>,
pat: P<ast::Pat>,
items: SmallVector<P<ast::Item>>,
syntax: move MethMac to MacImplItem and combine {Provided,Required}Method into MethodTraitItem.
2015-03-11 23:38:58 +02:00
impl_items: SmallVector<P<ast::ImplItem>>,
Replace MacExpr / MacPat / MacItems with MacEager MacEager is a MacResult implementation for the common case where you've already built each form of AST that you might return. Fixes #17637. Based on #18814. This is a [breaking-change] for syntax extensions: * MacExpr::new becomes MacEager::expr. * MacPat::new becomes MacEager::pat. * MacItems::new becomes MacEager::items. It takes a SmallVector directly, not an iterator.
2015-02-27 11:14:42 -08:00
stmt: P<ast::Stmt>,
Add patterns to MacResult
2014-05-19 13:32:51 -07:00
}
Replace MacExpr / MacPat / MacItems with MacEager MacEager is a MacResult implementation for the common case where you've already built each form of AST that you might return. Fixes #17637. Based on #18814. This is a [breaking-change] for syntax extensions: * MacExpr::new becomes MacEager::expr. * MacPat::new becomes MacEager::pat. * MacItems::new becomes MacEager::items. It takes a SmallVector directly, not an iterator.
2015-02-27 11:14:42 -08:00
impl MacResult for MacEager {
fn make_expr(self: Box<Self>) -> Option<P<ast::Expr>> {
self.expr
Add patterns to MacResult
2014-05-19 13:32:51 -07:00
}
Replace MacExpr / MacPat / MacItems with MacEager MacEager is a MacResult implementation for the common case where you've already built each form of AST that you might return. Fixes #17637. Based on #18814. This is a [breaking-change] for syntax extensions: * MacExpr::new becomes MacEager::expr. * MacPat::new becomes MacEager::pat. * MacItems::new becomes MacEager::items. It takes a SmallVector directly, not an iterator.
2015-02-27 11:14:42 -08:00
fn make_items(self: Box<Self>) -> Option<SmallVector<P<ast::Item>>> {
self.items
Add patterns to MacResult
2014-05-19 13:32:51 -07:00
}
Allow syntax extensions to return multiple items, closes #16723. This patch replaces `MacItem` with `MacItems`.
2014-09-13 12:55:00 +02:00
syntax: move MethMac to MacImplItem and combine {Provided,Required}Method into MethodTraitItem.
2015-03-11 23:38:58 +02:00
fn make_impl_items(self: Box<Self>) -> Option<SmallVector<P<ast::ImplItem>>> {
self.impl_items
Replace MacExpr / MacPat / MacItems with MacEager MacEager is a MacResult implementation for the common case where you've already built each form of AST that you might return. Fixes #17637. Based on #18814. This is a [breaking-change] for syntax extensions: * MacExpr::new becomes MacEager::expr. * MacPat::new becomes MacEager::pat. * MacItems::new becomes MacEager::items. It takes a SmallVector directly, not an iterator.
2015-02-27 11:14:42 -08:00
}
fn make_stmt(self: Box<Self>) -> Option<P<ast::Stmt>> {
match self.stmt {
None => make_stmt_default!(self),
s => s,
}
syntax: unify all MacResult's into a single trait. There's now one unified way to return things from a macro, instead of being able to choose the `AnyMacro` trait or the `MRItem`/`MRExpr` variants of the `MacResult` enum. This does simplify the logic handling the expansions, but the biggest value of this is it makes macros in (for example) type position easier to implement, as there's this single thing to modify. By my measurements (using `-Z time-passes` on libstd and librustc etc.), this appears to have little-to-no impact on expansion speed. There are presumably larger costs than the small number of extra allocations and virtual calls this adds (notably, all `macro_rules!`-defined macros have not changed in behaviour, since they had to use the `AnyMacro` trait anyway).
2014-04-15 22:00:14 +10:00
}
Allow syntax extensions to return multiple items, closes #16723. This patch replaces `MacItem` with `MacItems`.
2014-09-13 12:55:00 +02:00
Replace MacExpr / MacPat / MacItems with MacEager MacEager is a MacResult implementation for the common case where you've already built each form of AST that you might return. Fixes #17637. Based on #18814. This is a [breaking-change] for syntax extensions: * MacExpr::new becomes MacEager::expr. * MacPat::new becomes MacEager::pat. * MacItems::new becomes MacEager::items. It takes a SmallVector directly, not an iterator.
2015-02-27 11:14:42 -08:00
fn make_pat(self: Box<Self>) -> Option<P<ast::Pat>> {
if let Some(p) = self.pat {
return Some(p);
}
if let Some(e) = self.expr {
if let ast::ExprLit(_) = e.node {
return Some(P(ast::Pat {
id: ast::DUMMY_NODE_ID,
span: e.span,
node: ast::PatLit(e),
}));
}
}
None
syntax: unify all MacResult's into a single trait. There's now one unified way to return things from a macro, instead of being able to choose the `AnyMacro` trait or the `MRItem`/`MRExpr` variants of the `MacResult` enum. This does simplify the logic handling the expansions, but the biggest value of this is it makes macros in (for example) type position easier to implement, as there's this single thing to modify. By my measurements (using `-Z time-passes` on libstd and librustc etc.), this appears to have little-to-no impact on expansion speed. There are presumably larger costs than the small number of extra allocations and virtual calls this adds (notably, all `macro_rules!`-defined macros have not changed in behaviour, since they had to use the `AnyMacro` trait anyway).
2014-04-15 22:00:14 +10:00
}
}
Avoid returning original macro if expansion fails. Closes #11692. Instead of returning the original expression, a dummy expression (with identical span) is returned. This prevents infinite loops of failed expansions as well as odd double error messages in certain situations.
2014-02-18 16:14:12 +00:00
syntax: unify all MacResult's into a single trait. There's now one unified way to return things from a macro, instead of being able to choose the `AnyMacro` trait or the `MRItem`/`MRExpr` variants of the `MacResult` enum. This does simplify the logic handling the expansions, but the biggest value of this is it makes macros in (for example) type position easier to implement, as there's this single thing to modify. By my measurements (using `-Z time-passes` on libstd and librustc etc.), this appears to have little-to-no impact on expansion speed. There are presumably larger costs than the small number of extra allocations and virtual calls this adds (notably, all `macro_rules!`-defined macros have not changed in behaviour, since they had to use the `AnyMacro` trait anyway).
2014-04-15 22:00:14 +10:00
/// Fill-in macro expansion result, to allow compilation to continue
/// after hitting errors.
Fallout in libsyntax
2015-03-30 09:38:59 -04:00
#[derive(Copy, Clone)]
syntax: unify all MacResult's into a single trait. There's now one unified way to return things from a macro, instead of being able to choose the `AnyMacro` trait or the `MRItem`/`MRExpr` variants of the `MacResult` enum. This does simplify the logic handling the expansions, but the biggest value of this is it makes macros in (for example) type position easier to implement, as there's this single thing to modify. By my measurements (using `-Z time-passes` on libstd and librustc etc.), this appears to have little-to-no impact on expansion speed. There are presumably larger costs than the small number of extra allocations and virtual calls this adds (notably, all `macro_rules!`-defined macros have not changed in behaviour, since they had to use the `AnyMacro` trait anyway).
2014-04-15 22:00:14 +10:00
pub struct DummyResult {
expr_only: bool,
span: Span
Enable item macros to define macros.
2012-07-06 14:29:50 -07:00
}
syntax: unify all MacResult's into a single trait. There's now one unified way to return things from a macro, instead of being able to choose the `AnyMacro` trait or the `MRItem`/`MRExpr` variants of the `MacResult` enum. This does simplify the logic handling the expansions, but the biggest value of this is it makes macros in (for example) type position easier to implement, as there's this single thing to modify. By my measurements (using `-Z time-passes` on libstd and librustc etc.), this appears to have little-to-no impact on expansion speed. There are presumably larger costs than the small number of extra allocations and virtual calls this adds (notably, all `macro_rules!`-defined macros have not changed in behaviour, since they had to use the `AnyMacro` trait anyway).
2014-04-15 22:00:14 +10:00
impl DummyResult {
/// Create a default MacResult that can be anything.
///
/// Use this as a return value after hitting any errors and
/// calling `span_err`.
Implement generalized object and type parameter bounds (Fixes #16462)
2014-08-27 21:46:52 -04:00
pub fn any(sp: Span) -> Box<MacResult+'static> {
Add trivial cast lints. This permits all coercions to be performed in casts, but adds lints to warn in those cases. Part of this patch moves cast checking to a later stage of type checking. We acquire obligations to check casts as part of type checking where we previously checked them. Once we have type checked a function or module, then we check any cast obligations which have been acquired. That means we have more type information available to check casts (this was crucial to making coercions work properly in place of some casts), but it means that casts cannot feed input into type inference. [breaking change] * Adds two new lints for trivial casts and trivial numeric casts, these are warn by default, but can cause errors if you build with warnings as errors. Previously, trivial numeric casts and casts to trait objects were allowed. * The unused casts lint has gone. * Interactions between casting and type inference have changed in subtle ways. Two ways this might manifest are: - You may need to 'direct' casts more with extra type information, for example, in some cases where `foo as _ as T` succeeded, you may now need to specify the type for `_` - Casts do not influence inference of integer types. E.g., the following used to type check: ``` let x = 42; let y = &x as *const u32; ``` Because the cast would inform inference that `x` must have type `u32`. This no longer applies and the compiler will fallback to `i32` for `x` and thus there will be a type error in the cast. The solution is to add more type information: ``` let x: u32 = 42; let y = &x as *const u32; ```
2015-03-20 17:15:27 +13:00
box DummyResult { expr_only: false, span: sp }
syntax: unify all MacResult's into a single trait. There's now one unified way to return things from a macro, instead of being able to choose the `AnyMacro` trait or the `MRItem`/`MRExpr` variants of the `MacResult` enum. This does simplify the logic handling the expansions, but the biggest value of this is it makes macros in (for example) type position easier to implement, as there's this single thing to modify. By my measurements (using `-Z time-passes` on libstd and librustc etc.), this appears to have little-to-no impact on expansion speed. There are presumably larger costs than the small number of extra allocations and virtual calls this adds (notably, all `macro_rules!`-defined macros have not changed in behaviour, since they had to use the `AnyMacro` trait anyway).
2014-04-15 22:00:14 +10:00
}
/// Create a default MacResult that can only be an expression.
///
/// Use this for macros that must expand to an expression, so even
Fix more misspelled comments and strings.
2014-06-09 00:00:52 -04:00
/// if an error is encountered internally, the user will receive
syntax: unify all MacResult's into a single trait. There's now one unified way to return things from a macro, instead of being able to choose the `AnyMacro` trait or the `MRItem`/`MRExpr` variants of the `MacResult` enum. This does simplify the logic handling the expansions, but the biggest value of this is it makes macros in (for example) type position easier to implement, as there's this single thing to modify. By my measurements (using `-Z time-passes` on libstd and librustc etc.), this appears to have little-to-no impact on expansion speed. There are presumably larger costs than the small number of extra allocations and virtual calls this adds (notably, all `macro_rules!`-defined macros have not changed in behaviour, since they had to use the `AnyMacro` trait anyway).
2014-04-15 22:00:14 +10:00
/// an error that they also used it in the wrong place.
Implement generalized object and type parameter bounds (Fixes #16462)
2014-08-27 21:46:52 -04:00
pub fn expr(sp: Span) -> Box<MacResult+'static> {
Add trivial cast lints. This permits all coercions to be performed in casts, but adds lints to warn in those cases. Part of this patch moves cast checking to a later stage of type checking. We acquire obligations to check casts as part of type checking where we previously checked them. Once we have type checked a function or module, then we check any cast obligations which have been acquired. That means we have more type information available to check casts (this was crucial to making coercions work properly in place of some casts), but it means that casts cannot feed input into type inference. [breaking change] * Adds two new lints for trivial casts and trivial numeric casts, these are warn by default, but can cause errors if you build with warnings as errors. Previously, trivial numeric casts and casts to trait objects were allowed. * The unused casts lint has gone. * Interactions between casting and type inference have changed in subtle ways. Two ways this might manifest are: - You may need to 'direct' casts more with extra type information, for example, in some cases where `foo as _ as T` succeeded, you may now need to specify the type for `_` - Casts do not influence inference of integer types. E.g., the following used to type check: ``` let x = 42; let y = &x as *const u32; ``` Because the cast would inform inference that `x` must have type `u32`. This no longer applies and the compiler will fallback to `i32` for `x` and thus there will be a type error in the cast. The solution is to add more type information: ``` let x: u32 = 42; let y = &x as *const u32; ```
2015-03-20 17:15:27 +13:00
box DummyResult { expr_only: true, span: sp }
syntax: unify all MacResult's into a single trait. There's now one unified way to return things from a macro, instead of being able to choose the `AnyMacro` trait or the `MRItem`/`MRExpr` variants of the `MacResult` enum. This does simplify the logic handling the expansions, but the biggest value of this is it makes macros in (for example) type position easier to implement, as there's this single thing to modify. By my measurements (using `-Z time-passes` on libstd and librustc etc.), this appears to have little-to-no impact on expansion speed. There are presumably larger costs than the small number of extra allocations and virtual calls this adds (notably, all `macro_rules!`-defined macros have not changed in behaviour, since they had to use the `AnyMacro` trait anyway).
2014-04-15 22:00:14 +10:00
}
/// A plain dummy expression.
syntax: fix fallout from using ptr::P.
2014-09-13 19:06:01 +03:00
pub fn raw_expr(sp: Span) -> P<ast::Expr> {
P(ast::Expr {
Avoid returning original macro if expansion fails. Closes #11692. Instead of returning the original expression, a dummy expression (with identical span) is returned. This prevents infinite loops of failed expansions as well as odd double error messages in certain situations.
2014-02-18 16:14:12 +00:00
id: ast::DUMMY_NODE_ID,
Complete the removal of ty_nil, ast::LitNil, ast::TyBot and ast::TyUniq [breaking-change] This will break any uses of macros that assumed () being a valid literal.
2014-11-09 16:14:15 +01:00
node: ast::ExprLit(P(codemap::respan(sp, ast::LitBool(false)))),
syntax: allow `trace_macros!` and `log_syntax!` in item position. Previously trace_macros!(true) fn main() {} would complain about `trace_macros` being an expression macro in item position. This is a pointless limitation, because the macro is purely compile-time, with no runtime effect. (And similarly for log_syntax.) This also changes the behaviour of `trace_macros!` very slightly, it used to be equivalent to macro_rules! trace_macros { (true $($_x: tt)*) => { true }; (false $($_x: tt)*) => { false } } I.e. you could invoke it with arbitrary trailing arguments, which were ignored. It is changed to accept only exactly `true` or `false` (with no trailing arguments) and expands to `()`.
2014-03-18 23:14:08 +11:00
span: sp,
syntax: fix fallout from using ptr::P.
2014-09-13 19:06:01 +03:00
})
Avoid returning original macro if expansion fails. Closes #11692. Instead of returning the original expression, a dummy expression (with identical span) is returned. This prevents infinite loops of failed expansions as well as odd double error messages in certain situations.
2014-02-18 16:14:12 +00:00
}
Add patterns to MacResult
2014-05-19 13:32:51 -07:00
/// A plain dummy pattern.
syntax: fix fallout from using ptr::P.
2014-09-13 19:06:01 +03:00
pub fn raw_pat(sp: Span) -> ast::Pat {
ast::Pat {
Add patterns to MacResult
2014-05-19 13:32:51 -07:00
id: ast::DUMMY_NODE_ID,
AST refactoring: merge PatWild and PatWildMulti into one variant with a flag.
2014-08-06 17:04:44 +02:00
node: ast::PatWild(ast::PatWildSingle),
Add patterns to MacResult
2014-05-19 13:32:51 -07:00
span: sp,
}
}
add make_method method to MacResult trait this allows macro results to be parsed as methods
2014-07-10 17:46:09 -07:00
syntax: allow `trace_macros!` and `log_syntax!` in item position. Previously trace_macros!(true) fn main() {} would complain about `trace_macros` being an expression macro in item position. This is a pointless limitation, because the macro is purely compile-time, with no runtime effect. (And similarly for log_syntax.) This also changes the behaviour of `trace_macros!` very slightly, it used to be equivalent to macro_rules! trace_macros { (true $($_x: tt)*) => { true }; (false $($_x: tt)*) => { false } } I.e. you could invoke it with arbitrary trailing arguments, which were ignored. It is changed to accept only exactly `true` or `false` (with no trailing arguments) and expands to `()`.
2014-03-18 23:14:08 +11:00
}
syntax: unify all MacResult's into a single trait. There's now one unified way to return things from a macro, instead of being able to choose the `AnyMacro` trait or the `MRItem`/`MRExpr` variants of the `MacResult` enum. This does simplify the logic handling the expansions, but the biggest value of this is it makes macros in (for example) type position easier to implement, as there's this single thing to modify. By my measurements (using `-Z time-passes` on libstd and librustc etc.), this appears to have little-to-no impact on expansion speed. There are presumably larger costs than the small number of extra allocations and virtual calls this adds (notably, all `macro_rules!`-defined macros have not changed in behaviour, since they had to use the `AnyMacro` trait anyway).
2014-04-15 22:00:14 +10:00
impl MacResult for DummyResult {
syntax: fix fallout from using ptr::P.
2014-09-13 19:06:01 +03:00
fn make_expr(self: Box<DummyResult>) -> Option<P<ast::Expr>> {
syntax: unify all MacResult's into a single trait. There's now one unified way to return things from a macro, instead of being able to choose the `AnyMacro` trait or the `MRItem`/`MRExpr` variants of the `MacResult` enum. This does simplify the logic handling the expansions, but the biggest value of this is it makes macros in (for example) type position easier to implement, as there's this single thing to modify. By my measurements (using `-Z time-passes` on libstd and librustc etc.), this appears to have little-to-no impact on expansion speed. There are presumably larger costs than the small number of extra allocations and virtual calls this adds (notably, all `macro_rules!`-defined macros have not changed in behaviour, since they had to use the `AnyMacro` trait anyway).
2014-04-15 22:00:14 +10:00
Some(DummyResult::raw_expr(self.span))
syntax: allow `trace_macros!` and `log_syntax!` in item position. Previously trace_macros!(true) fn main() {} would complain about `trace_macros` being an expression macro in item position. This is a pointless limitation, because the macro is purely compile-time, with no runtime effect. (And similarly for log_syntax.) This also changes the behaviour of `trace_macros!` very slightly, it used to be equivalent to macro_rules! trace_macros { (true $($_x: tt)*) => { true }; (false $($_x: tt)*) => { false } } I.e. you could invoke it with arbitrary trailing arguments, which were ignored. It is changed to accept only exactly `true` or `false` (with no trailing arguments) and expands to `()`.
2014-03-18 23:14:08 +11:00
}
syntax: fix fallout from using ptr::P.
2014-09-13 19:06:01 +03:00
fn make_pat(self: Box<DummyResult>) -> Option<P<ast::Pat>> {
Some(P(DummyResult::raw_pat(self.span)))
Add patterns to MacResult
2014-05-19 13:32:51 -07:00
}
syntax: fix fallout from using ptr::P.
2014-09-13 19:06:01 +03:00
fn make_items(self: Box<DummyResult>) -> Option<SmallVector<P<ast::Item>>> {
add make_method method to MacResult trait this allows macro results to be parsed as methods
2014-07-10 17:46:09 -07:00
// this code needs a comment... why not always just return the Some() ?
if self.expr_only {
None
} else {
Some(SmallVector::zero())
}
}
syntax: move MethMac to MacImplItem and combine {Provided,Required}Method into MethodTraitItem.
2015-03-11 23:38:58 +02:00
fn make_impl_items(self: Box<DummyResult>) -> Option<SmallVector<P<ast::ImplItem>>> {
syntax: unify all MacResult's into a single trait. There's now one unified way to return things from a macro, instead of being able to choose the `AnyMacro` trait or the `MRItem`/`MRExpr` variants of the `MacResult` enum. This does simplify the logic handling the expansions, but the biggest value of this is it makes macros in (for example) type position easier to implement, as there's this single thing to modify. By my measurements (using `-Z time-passes` on libstd and librustc etc.), this appears to have little-to-no impact on expansion speed. There are presumably larger costs than the small number of extra allocations and virtual calls this adds (notably, all `macro_rules!`-defined macros have not changed in behaviour, since they had to use the `AnyMacro` trait anyway).
2014-04-15 22:00:14 +10:00
if self.expr_only {
None
} else {
Some(SmallVector::zero())
}
syntax: allow `trace_macros!` and `log_syntax!` in item position. Previously trace_macros!(true) fn main() {} would complain about `trace_macros` being an expression macro in item position. This is a pointless limitation, because the macro is purely compile-time, with no runtime effect. (And similarly for log_syntax.) This also changes the behaviour of `trace_macros!` very slightly, it used to be equivalent to macro_rules! trace_macros { (true $($_x: tt)*) => { true }; (false $($_x: tt)*) => { false } } I.e. you could invoke it with arbitrary trailing arguments, which were ignored. It is changed to accept only exactly `true` or `false` (with no trailing arguments) and expands to `()`.
2014-03-18 23:14:08 +11:00
}
syntax: fix fallout from using ptr::P.
2014-09-13 19:06:01 +03:00
fn make_stmt(self: Box<DummyResult>) -> Option<P<ast::Stmt>> {
Some(P(codemap::respan(self.span,
ast::StmtExpr(DummyResult::raw_expr(self.span),
ast::DUMMY_NODE_ID))))
syntax: allow `trace_macros!` and `log_syntax!` in item position. Previously trace_macros!(true) fn main() {} would complain about `trace_macros` being an expression macro in item position. This is a pointless limitation, because the macro is purely compile-time, with no runtime effect. (And similarly for log_syntax.) This also changes the behaviour of `trace_macros!` very slightly, it used to be equivalent to macro_rules! trace_macros { (true $($_x: tt)*) => { true }; (false $($_x: tt)*) => { false } } I.e. you could invoke it with arbitrary trailing arguments, which were ignored. It is changed to accept only exactly `true` or `false` (with no trailing arguments) and expands to `()`.
2014-03-18 23:14:08 +11:00
}
syntax::ext: replace span_fatal with span_err in many places. This means that compilation continues for longer, and so we can see more errors per compile. This is mildly more user-friendly because it stops users having to run rustc n times to see n macro errors: just run it once to see all of them.
2014-01-18 01:53:10 +11:00
}
Plumbing and parsing for item-position macros.
2012-07-05 12:10:33 -07:00
Add an ItemModifier syntax extension type Where ItemDecorator creates new items given a single item, ItemModifier alters the tagged item in place. The expansion rules for this are a bit weird, but I think are the most reasonable option available. When an item is expanded, all ItemModifier attributes are stripped from it and the item is folded through all ItemModifiers. At that point, the process repeats until there are no ItemModifiers in the new item.
2014-02-27 23:49:25 -08:00
/// An enum representing the different kinds of syntax extensions.
libsyntax: De-export libsyntax. rs=deexporting
2013-01-29 14:41:40 -08:00
pub enum SyntaxExtension {
Add an ItemModifier syntax extension type Where ItemDecorator creates new items given a single item, ItemModifier alters the tagged item in place. The expansion rules for this are a bit weird, but I think are the most reasonable option available. When an item is expanded, all ItemModifier attributes are stripped from it and the item is folded through all ItemModifiers. At that point, the process repeats until there are no ItemModifiers in the new item.
2014-02-27 23:49:25 -08:00
/// A syntax extension that is attached to an item and creates new items
/// based upon it.
///
sed -i -s 's/#\[deriving(/#\[derive(/g' **/*.rs
2015-01-03 22:54:18 -05:00
/// `#[derive(...)]` is an `ItemDecorator`.
Add enum variants to the type namespace Change to resolve and update compiler and libs for uses. [breaking-change] Enum variants are now in both the value and type namespaces. This means that if you have a variant with the same name as a type in scope in a module, you will get a name clash and thus an error. The solution is to either rename the type or the variant.
2014-09-11 17:07:49 +12:00
Decorator(Box<ItemDecorator + 'static>),
Make it possible to make built-in tt syntax extensions
2012-06-25 15:04:50 -07:00
Add an ItemModifier syntax extension type Where ItemDecorator creates new items given a single item, ItemModifier alters the tagged item in place. The expansion rules for this are a bit weird, but I think are the most reasonable option available. When an item is expanded, all ItemModifier attributes are stripped from it and the item is folded through all ItemModifiers. At that point, the process repeats until there are no ItemModifiers in the new item.
2014-02-27 23:49:25 -08:00
/// A syntax extension that is attached to an item and modifies it
/// in-place.
Add enum variants to the type namespace Change to resolve and update compiler and libs for uses. [breaking-change] Enum variants are now in both the value and type namespaces. This means that if you have a variant with the same name as a type in scope in a module, you will get a name clash and thus an error. The solution is to either rename the type or the variant.
2014-09-11 17:07:49 +12:00
Modifier(Box<ItemModifier + 'static>),
Make it possible to invoke item macros without passing identifier arguments.
2012-11-08 23:12:45 -05:00
Syntax extensions on trait and impl items. Allows modifiers to be used on methods, associated types, etc.
2014-12-02 10:07:41 -08:00
/// A syntax extension that is attached to an item and modifies it
/// in-place. More flexible version than Modifier.
MultiModifier(Box<MultiItemModifier + 'static>),
Add an ItemModifier syntax extension type Where ItemDecorator creates new items given a single item, ItemModifier alters the tagged item in place. The expansion rules for this are a bit weird, but I think are the most reasonable option available. When an item is expanded, all ItemModifier attributes are stripped from it and the item is folded through all ItemModifiers. At that point, the process repeats until there are no ItemModifiers in the new item.
2014-02-27 23:49:25 -08:00
/// A normal, function-like syntax extension.
///
/// `bytes!` is a `NormalTT`.
Add #[allow_internal_unstable] to track stability for macros better. Unstable items used in a macro expansion will now always trigger stability warnings, *unless* the unstable items are directly inside a macro marked with `#[allow_internal_unstable]`. IOW, the compiler warns unless the span of the unstable item is a subspan of the definition of a macro marked with that attribute. E.g. #[allow_internal_unstable] macro_rules! foo { ($e: expr) => {{ $e; unstable(); // no warning only_called_by_foo!(); }} } macro_rules! only_called_by_foo { () => { unstable() } // warning } foo!(unstable()) // warning The unstable inside `foo` is fine, due to the attribute. But the `unstable` inside `only_called_by_foo` is not, since that macro doesn't have the attribute, and the `unstable` passed into `foo` is also not fine since it isn't contained in the macro itself (that is, even though it is only used directly in the macro). In the process this makes the stability tracking much more precise, e.g. previously `println!("{}", unstable())` got no warning, but now it does. As such, this is a bug fix that may cause [breaking-change]s. The attribute is definitely feature gated, since it explicitly allows side-stepping the feature gating system.
2015-03-01 14:09:28 +11:00
///
/// The `bool` dictates whether the contents of the macro can
/// directly use `#[unstable]` things (true == yes).
NormalTT(Box<TTMacroExpander + 'static>, Option<Span>, bool),
Macros now leave scope Macro scope is now delimited by function, block, and module boundaries, except for modules that are marked with #[macro_escape], which allows macros to escape.
2013-02-26 10:15:29 -08:00
Add an ItemModifier syntax extension type Where ItemDecorator creates new items given a single item, ItemModifier alters the tagged item in place. The expansion rules for this are a bit weird, but I think are the most reasonable option available. When an item is expanded, all ItemModifier attributes are stripped from it and the item is folded through all ItemModifiers. At that point, the process repeats until there are no ItemModifiers in the new item.
2014-02-27 23:49:25 -08:00
/// A function-like syntax extension that has an extra ident before
/// the block.
///
Add #[allow_internal_unstable] to track stability for macros better. Unstable items used in a macro expansion will now always trigger stability warnings, *unless* the unstable items are directly inside a macro marked with `#[allow_internal_unstable]`. IOW, the compiler warns unless the span of the unstable item is a subspan of the definition of a macro marked with that attribute. E.g. #[allow_internal_unstable] macro_rules! foo { ($e: expr) => {{ $e; unstable(); // no warning only_called_by_foo!(); }} } macro_rules! only_called_by_foo { () => { unstable() } // warning } foo!(unstable()) // warning The unstable inside `foo` is fine, due to the attribute. But the `unstable` inside `only_called_by_foo` is not, since that macro doesn't have the attribute, and the `unstable` passed into `foo` is also not fine since it isn't contained in the macro itself (that is, even though it is only used directly in the macro). In the process this makes the stability tracking much more precise, e.g. previously `println!("{}", unstable())` got no warning, but now it does. As such, this is a bug fix that may cause [breaking-change]s. The attribute is definitely feature gated, since it explicitly allows side-stepping the feature gating system.
2015-03-01 14:09:28 +11:00
IdentTT(Box<IdentMacroExpander + 'static>, Option<Span>, bool),
introducing let-syntax The let-syntax expander is different in that it doesn't apply a mark to its token trees before expansion. This is used for macro_rules, and it's because macro_rules is essentially MTWT's let-syntax. You don't want to mark before expand sees let-syntax, because there's no "after" syntax to mark again. In some sense, the cleaner approach might be to introduce a new AST node that macro_rules expands into; this would make it clearer that the expansion of a macro is distinct from the addition of a new macro binding. This should work for now, though...
2014-07-07 09:54:08 -07:00
Replace LetSyntaxTT with MacroRulesTT The implementation of LetSyntaxTT was specialized to macro_rules! in various ways. This gets rid of the false generality and simplifies the code.
2014-09-15 16:09:09 -07:00
/// Represents `macro_rules!` itself.
MacroRulesTT,
Add simple syntax extension (#simplext)
2011-06-20 17:26:17 -07:00
}
rustc: Introduce ext module. Move some things from parser to ext. Introduce an ext_ctxt record to provide a span_err method for use while expanding syntax extensions. Hopefully it will be useful for other things.
2011-06-04 15:41:45 -04:00
Implement #[plugin_registrar] See RFC 22. [breaking-change]
2014-05-24 16:16:10 -07:00
pub type NamedSyntaxExtension = (Name, SyntaxExtension);
change to newer macro escape mechanism, using uints in more places
2013-05-08 15:27:29 -07:00
pub struct BlockInfo {
syntax: doc comments all the things
2014-06-09 13:12:30 -07:00
/// Should macros escape from this scope?
syntax: Switch field privacy as necessary
2014-03-27 15:39:48 -07:00
pub macros_escape: bool,
syntax: doc comments all the things
2014-06-09 13:12:30 -07:00
/// What are the pending renames?
move RenameList to mtwt, add new_renames abstraction
2014-07-02 22:38:30 -07:00
pub pending_renames: mtwt::RenameList,
Rewrite SyntaxEnv I'd really like to be able to do something like struct MapChain<'next, K, V> { info: BlockInfo, map: HashMap<K, V>, next: Option<&'next mut MapChain<'next, K, V> } but I can't get the lifetimes to work out.
2013-12-30 17:45:39 -08:00
}
impl BlockInfo {
pub fn new() -> BlockInfo {
BlockInfo {
macros_escape: false,
libsyntax: Mechanically change `~[T]` to `Vec<T>`
2014-02-28 13:09:09 -08:00
pending_renames: Vec::new(),
Rewrite SyntaxEnv I'd really like to be able to do something like struct MapChain<'next, K, V> { info: BlockInfo, map: HashMap<K, V>, next: Option<&'next mut MapChain<'next, K, V> } but I can't get the lifetimes to work out.
2013-12-30 17:45:39 -08:00
}
}
Macros now leave scope Macro scope is now delimited by function, block, and module boundaries, except for modules that are marked with #[macro_escape], which allows macros to escape.
2013-02-26 10:15:29 -08:00
}
Alias HashMap<~str, SyntaxExtension> to SyntaxExtensions
2013-02-13 20:08:35 -08:00
syntax: doc comments all the things
2014-06-09 13:12:30 -07:00
/// The base map of methods for expanding syntax extension
/// AST nodes into full ASTs
libsyntax: Pass feature set in ExpansionConfig, not just enable_quotes.
2015-02-15 21:30:45 +01:00
fn initial_syntax_expander_table<'feat>(ecfg: &expand::ExpansionConfig<'feat>)
-> SyntaxEnv {
Commenting, test cases, cleanup
2013-02-04 13:15:17 -08:00
// utility function to simplify creating NormalTT syntax extensions
Simplify and rename macro API Now that procedural macros can be implemented outside of the compiler, it's more important to have a reasonable API to work with. Here are the basic changes: * Rename SyntaxExpanderTTTrait to MacroExpander, SyntaxExpanderTT to BasicMacroExpander, etc. I think "procedural macro" is the right term for these now, right? The other option would be SynExtExpander or something like that. * Stop passing the SyntaxContext to extensions. This was only ever used by macro_rules, which doesn't even use it anymore. I can't think of a context in which an external extension would need it, and removal allows the API to be significantly simpler - no more SyntaxExpanderTTItemExpanderWithoutContext wrappers to worry about.
2014-01-25 13:34:26 -08:00
fn builtin_normal_expander(f: MacroExpanderFn) -> SyntaxExtension {
Add #[allow_internal_unstable] to track stability for macros better. Unstable items used in a macro expansion will now always trigger stability warnings, *unless* the unstable items are directly inside a macro marked with `#[allow_internal_unstable]`. IOW, the compiler warns unless the span of the unstable item is a subspan of the definition of a macro marked with that attribute. E.g. #[allow_internal_unstable] macro_rules! foo { ($e: expr) => {{ $e; unstable(); // no warning only_called_by_foo!(); }} } macro_rules! only_called_by_foo { () => { unstable() } // warning } foo!(unstable()) // warning The unstable inside `foo` is fine, due to the attribute. But the `unstable` inside `only_called_by_foo` is not, since that macro doesn't have the attribute, and the `unstable` passed into `foo` is also not fine since it isn't contained in the macro itself (that is, even though it is only used directly in the macro). In the process this makes the stability tracking much more precise, e.g. previously `println!("{}", unstable())` got no warning, but now it does. As such, this is a bug fix that may cause [breaking-change]s. The attribute is definitely feature gated, since it explicitly allows side-stepping the feature gating system.
2015-03-01 14:09:28 +11:00
NormalTT(Box::new(f), None, false)
remove the old auto_serialize syntax extension
2012-10-07 14:56:18 -07:00
}
Remove dead codes
2013-12-08 02:55:28 -05:00
Load macros from external modules
2013-12-25 11:10:33 -07:00
let mut syntax_expanders = SyntaxEnv::new();
Replace LetSyntaxTT with MacroRulesTT The implementation of LetSyntaxTT was specialized to macro_rules! in various ways. This gets rid of the false generality and simplifies the code.
2014-09-15 16:09:09 -07:00
syntax_expanders.insert(intern("macro_rules"), MacroRulesTT);
librustc: Remove `~"string"` and `&"string"` from the language
2014-04-30 16:49:12 -07:00
syntax_expanders.insert(intern("format_args"),
Add #[allow_internal_unstable] to track stability for macros better. Unstable items used in a macro expansion will now always trigger stability warnings, *unless* the unstable items are directly inside a macro marked with `#[allow_internal_unstable]`. IOW, the compiler warns unless the span of the unstable item is a subspan of the definition of a macro marked with that attribute. E.g. #[allow_internal_unstable] macro_rules! foo { ($e: expr) => {{ $e; unstable(); // no warning only_called_by_foo!(); }} } macro_rules! only_called_by_foo { () => { unstable() } // warning } foo!(unstable()) // warning The unstable inside `foo` is fine, due to the attribute. But the `unstable` inside `only_called_by_foo` is not, since that macro doesn't have the attribute, and the `unstable` passed into `foo` is also not fine since it isn't contained in the macro itself (that is, even though it is only used directly in the macro). In the process this makes the stability tracking much more precise, e.g. previously `println!("{}", unstable())` got no warning, but now it does. As such, this is a bug fix that may cause [breaking-change]s. The attribute is definitely feature gated, since it explicitly allows side-stepping the feature gating system.
2015-03-01 14:09:28 +11:00
// format_args uses `unstable` things internally.
NormalTT(Box::new(ext::format::expand_format_args), None, true));
librustc: Remove `~"string"` and `&"string"` from the language
2014-04-30 16:49:12 -07:00
syntax_expanders.insert(intern("env"),
Simplify and rename macro API Now that procedural macros can be implemented outside of the compiler, it's more important to have a reasonable API to work with. Here are the basic changes: * Rename SyntaxExpanderTTTrait to MacroExpander, SyntaxExpanderTT to BasicMacroExpander, etc. I think "procedural macro" is the right term for these now, right? The other option would be SynExtExpander or something like that. * Stop passing the SyntaxContext to extensions. This was only ever used by macro_rules, which doesn't even use it anymore. I can't think of a context in which an external extension would need it, and removal allows the API to be significantly simpler - no more SyntaxExpanderTTItemExpanderWithoutContext wrappers to worry about.
2014-01-25 13:34:26 -08:00
builtin_normal_expander(
libsyntax: Remove some more `@fn`s from the macro expander
2013-08-30 14:40:05 -07:00
ext::env::expand_env));
librustc: Remove `~"string"` and `&"string"` from the language
2014-04-30 16:49:12 -07:00
syntax_expanders.insert(intern("option_env"),
Simplify and rename macro API Now that procedural macros can be implemented outside of the compiler, it's more important to have a reasonable API to work with. Here are the basic changes: * Rename SyntaxExpanderTTTrait to MacroExpander, SyntaxExpanderTT to BasicMacroExpander, etc. I think "procedural macro" is the right term for these now, right? The other option would be SynExtExpander or something like that. * Stop passing the SyntaxContext to extensions. This was only ever used by macro_rules, which doesn't even use it anymore. I can't think of a context in which an external extension would need it, and removal allows the API to be significantly simpler - no more SyntaxExpanderTTItemExpanderWithoutContext wrappers to worry about.
2014-01-25 13:34:26 -08:00
builtin_normal_expander(
libsyntax: Remove some more `@fn`s from the macro expander
2013-08-30 14:40:05 -07:00
ext::env::expand_option_env));
change to newer macro escape mechanism, using uints in more places
2013-05-08 15:27:29 -07:00
syntax_expanders.insert(intern("concat_idents"),
Simplify and rename macro API Now that procedural macros can be implemented outside of the compiler, it's more important to have a reasonable API to work with. Here are the basic changes: * Rename SyntaxExpanderTTTrait to MacroExpander, SyntaxExpanderTT to BasicMacroExpander, etc. I think "procedural macro" is the right term for these now, right? The other option would be SynExtExpander or something like that. * Stop passing the SyntaxContext to extensions. This was only ever used by macro_rules, which doesn't even use it anymore. I can't think of a context in which an external extension would need it, and removal allows the API to be significantly simpler - no more SyntaxExpanderTTItemExpanderWithoutContext wrappers to worry about.
2014-01-25 13:34:26 -08:00
builtin_normal_expander(
libsyntax: Remove some more `@fn`s from the macro expander
2013-08-30 14:40:05 -07:00
ext::concat_idents::expand_syntax_ext));
Implement a concat!() format extension This extension can be used to concatenate string literals at compile time. C has this useful ability when placing string literals lexically next to one another, but this needs to be handled at the syntax extension level to recursively expand macros. The major use case for this is something like: macro_rules! mylog( ($fmt:expr $($arg:tt)*) => { error2!(concat!(file!(), ":", line!(), " - ", $fmt) $($arg)*); }) Where the mylog macro will automatically prepend the filename/line number to the beginning of every log message.
2013-10-05 21:15:46 -07:00
syntax_expanders.insert(intern("concat"),
Simplify and rename macro API Now that procedural macros can be implemented outside of the compiler, it's more important to have a reasonable API to work with. Here are the basic changes: * Rename SyntaxExpanderTTTrait to MacroExpander, SyntaxExpanderTT to BasicMacroExpander, etc. I think "procedural macro" is the right term for these now, right? The other option would be SynExtExpander or something like that. * Stop passing the SyntaxContext to extensions. This was only ever used by macro_rules, which doesn't even use it anymore. I can't think of a context in which an external extension would need it, and removal allows the API to be significantly simpler - no more SyntaxExpanderTTItemExpanderWithoutContext wrappers to worry about.
2014-01-25 13:34:26 -08:00
builtin_normal_expander(
Implement a concat!() format extension This extension can be used to concatenate string literals at compile time. C has this useful ability when placing string literals lexically next to one another, but this needs to be handled at the syntax extension level to recursively expand macros. The major use case for this is something like: macro_rules! mylog( ($fmt:expr $($arg:tt)*) => { error2!(concat!(file!(), ":", line!(), " - ", $fmt) $($arg)*); }) Where the mylog macro will automatically prepend the filename/line number to the beginning of every log message.
2013-10-05 21:15:46 -07:00
ext::concat::expand_syntax_ext));
librustc: Remove `~"string"` and `&"string"` from the language
2014-04-30 16:49:12 -07:00
syntax_expanders.insert(intern("log_syntax"),
Simplify and rename macro API Now that procedural macros can be implemented outside of the compiler, it's more important to have a reasonable API to work with. Here are the basic changes: * Rename SyntaxExpanderTTTrait to MacroExpander, SyntaxExpanderTT to BasicMacroExpander, etc. I think "procedural macro" is the right term for these now, right? The other option would be SynExtExpander or something like that. * Stop passing the SyntaxContext to extensions. This was only ever used by macro_rules, which doesn't even use it anymore. I can't think of a context in which an external extension would need it, and removal allows the API to be significantly simpler - no more SyntaxExpanderTTItemExpanderWithoutContext wrappers to worry about.
2014-01-25 13:34:26 -08:00
builtin_normal_expander(
libsyntax: Remove some more `@fn`s from the macro expander
2013-08-30 14:40:05 -07:00
ext::log_syntax::expand_syntax_ext));
Make #[derive(Anything)] into sugar for #[derive_Anything] This is a hack, but I don't think we can do much better as long as `derive` is running at the syntax expansion phase. If the custom_derive feature gate is enabled, this works with user-defined traits and syntax extensions. Without the gate, you can't use e.g. #[derive_Clone] directly, so this does not change the stable language. This commit also cleans up the deriving code somewhat, and forbids some previously-meaningless attribute syntax. For this reason it's technically a [breaking-change]
2015-03-06 13:15:54 -08:00
ext::deriving::register_all(&mut syntax_expanders);
syntax: rename quote! to quote_tokens!, add quote_{expr,type,item,pat,stmt}! r=brson, Close #3976.
2012-11-16 14:50:35 -08:00
libsyntax: Pass feature set in ExpansionConfig, not just enable_quotes.
2015-02-15 21:30:45 +01:00
if ecfg.enable_quotes() {
Hide the quote_*! macros when the feature gate is off This makes it easier to experiment with improved quasiquoting as an ordinary plugin library. The list of quote macros in feature_gate.rs was already out of sync; this commit also prevents that problem in the future.
2014-09-26 17:14:23 -07:00
// Quasi-quoting expanders
syntax_expanders.insert(intern("quote_tokens"),
builtin_normal_expander(
ext::quote::expand_quote_tokens));
syntax_expanders.insert(intern("quote_expr"),
builtin_normal_expander(
ext::quote::expand_quote_expr));
syntax_expanders.insert(intern("quote_ty"),
builtin_normal_expander(
ext::quote::expand_quote_ty));
syntax_expanders.insert(intern("quote_item"),
builtin_normal_expander(
ext::quote::expand_quote_item));
syntax_expanders.insert(intern("quote_pat"),
builtin_normal_expander(
ext::quote::expand_quote_pat));
syntax_expanders.insert(intern("quote_arm"),
builtin_normal_expander(
ext::quote::expand_quote_arm));
syntax_expanders.insert(intern("quote_stmt"),
builtin_normal_expander(
ext::quote::expand_quote_stmt));
Add quasiquote for matchers and attributes
2015-02-24 19:56:01 +01:00
syntax_expanders.insert(intern("quote_matcher"),
builtin_normal_expander(
ext::quote::expand_quote_matcher));
syntax_expanders.insert(intern("quote_attr"),
builtin_normal_expander(
ext::quote::expand_quote_attr));
Hide the quote_*! macros when the feature gate is off This makes it easier to experiment with improved quasiquoting as an ordinary plugin library. The list of quote macros in feature_gate.rs was already out of sync; this commit also prevents that problem in the future.
2014-09-26 17:14:23 -07:00
}
syntax: rename quote! to quote_tokens!, add quote_{expr,type,item,pat,stmt}! r=brson, Close #3976.
2012-11-16 14:50:35 -08:00
librustc: Remove `~"string"` and `&"string"` from the language
2014-04-30 16:49:12 -07:00
syntax_expanders.insert(intern("line"),
Simplify and rename macro API Now that procedural macros can be implemented outside of the compiler, it's more important to have a reasonable API to work with. Here are the basic changes: * Rename SyntaxExpanderTTTrait to MacroExpander, SyntaxExpanderTT to BasicMacroExpander, etc. I think "procedural macro" is the right term for these now, right? The other option would be SynExtExpander or something like that. * Stop passing the SyntaxContext to extensions. This was only ever used by macro_rules, which doesn't even use it anymore. I can't think of a context in which an external extension would need it, and removal allows the API to be significantly simpler - no more SyntaxExpanderTTItemExpanderWithoutContext wrappers to worry about.
2014-01-25 13:34:26 -08:00
builtin_normal_expander(
libsyntax: Remove some more `@fn`s from the macro expander
2013-08-30 14:40:05 -07:00
ext::source_util::expand_line));
Rename `col!` to `column!`. This macro is very rarely used, so there is no need (and it is better) for it to avoid the abbreviation. Closes rust-lang/rfcs#467. [breaking-change]
2014-11-18 23:03:58 +11:00
syntax_expanders.insert(intern("column"),
Simplify and rename macro API Now that procedural macros can be implemented outside of the compiler, it's more important to have a reasonable API to work with. Here are the basic changes: * Rename SyntaxExpanderTTTrait to MacroExpander, SyntaxExpanderTT to BasicMacroExpander, etc. I think "procedural macro" is the right term for these now, right? The other option would be SynExtExpander or something like that. * Stop passing the SyntaxContext to extensions. This was only ever used by macro_rules, which doesn't even use it anymore. I can't think of a context in which an external extension would need it, and removal allows the API to be significantly simpler - no more SyntaxExpanderTTItemExpanderWithoutContext wrappers to worry about.
2014-01-25 13:34:26 -08:00
builtin_normal_expander(
Rename `col!` to `column!`. This macro is very rarely used, so there is no need (and it is better) for it to avoid the abbreviation. Closes rust-lang/rfcs#467. [breaking-change]
2014-11-18 23:03:58 +11:00
ext::source_util::expand_column));
librustc: Remove `~"string"` and `&"string"` from the language
2014-04-30 16:49:12 -07:00
syntax_expanders.insert(intern("file"),
Simplify and rename macro API Now that procedural macros can be implemented outside of the compiler, it's more important to have a reasonable API to work with. Here are the basic changes: * Rename SyntaxExpanderTTTrait to MacroExpander, SyntaxExpanderTT to BasicMacroExpander, etc. I think "procedural macro" is the right term for these now, right? The other option would be SynExtExpander or something like that. * Stop passing the SyntaxContext to extensions. This was only ever used by macro_rules, which doesn't even use it anymore. I can't think of a context in which an external extension would need it, and removal allows the API to be significantly simpler - no more SyntaxExpanderTTItemExpanderWithoutContext wrappers to worry about.
2014-01-25 13:34:26 -08:00
builtin_normal_expander(
libsyntax: Remove some more `@fn`s from the macro expander
2013-08-30 14:40:05 -07:00
ext::source_util::expand_file));
librustc: Remove `~"string"` and `&"string"` from the language
2014-04-30 16:49:12 -07:00
syntax_expanders.insert(intern("stringify"),
Simplify and rename macro API Now that procedural macros can be implemented outside of the compiler, it's more important to have a reasonable API to work with. Here are the basic changes: * Rename SyntaxExpanderTTTrait to MacroExpander, SyntaxExpanderTT to BasicMacroExpander, etc. I think "procedural macro" is the right term for these now, right? The other option would be SynExtExpander or something like that. * Stop passing the SyntaxContext to extensions. This was only ever used by macro_rules, which doesn't even use it anymore. I can't think of a context in which an external extension would need it, and removal allows the API to be significantly simpler - no more SyntaxExpanderTTItemExpanderWithoutContext wrappers to worry about.
2014-01-25 13:34:26 -08:00
builtin_normal_expander(
libsyntax: Remove some more `@fn`s from the macro expander
2013-08-30 14:40:05 -07:00
ext::source_util::expand_stringify));
librustc: Remove `~"string"` and `&"string"` from the language
2014-04-30 16:49:12 -07:00
syntax_expanders.insert(intern("include"),
Simplify and rename macro API Now that procedural macros can be implemented outside of the compiler, it's more important to have a reasonable API to work with. Here are the basic changes: * Rename SyntaxExpanderTTTrait to MacroExpander, SyntaxExpanderTT to BasicMacroExpander, etc. I think "procedural macro" is the right term for these now, right? The other option would be SynExtExpander or something like that. * Stop passing the SyntaxContext to extensions. This was only ever used by macro_rules, which doesn't even use it anymore. I can't think of a context in which an external extension would need it, and removal allows the API to be significantly simpler - no more SyntaxExpanderTTItemExpanderWithoutContext wrappers to worry about.
2014-01-25 13:34:26 -08:00
builtin_normal_expander(
libsyntax: Remove some more `@fn`s from the macro expander
2013-08-30 14:40:05 -07:00
ext::source_util::expand_include));
librustc: Remove `~"string"` and `&"string"` from the language
2014-04-30 16:49:12 -07:00
syntax_expanders.insert(intern("include_str"),
Simplify and rename macro API Now that procedural macros can be implemented outside of the compiler, it's more important to have a reasonable API to work with. Here are the basic changes: * Rename SyntaxExpanderTTTrait to MacroExpander, SyntaxExpanderTT to BasicMacroExpander, etc. I think "procedural macro" is the right term for these now, right? The other option would be SynExtExpander or something like that. * Stop passing the SyntaxContext to extensions. This was only ever used by macro_rules, which doesn't even use it anymore. I can't think of a context in which an external extension would need it, and removal allows the API to be significantly simpler - no more SyntaxExpanderTTItemExpanderWithoutContext wrappers to worry about.
2014-01-25 13:34:26 -08:00
builtin_normal_expander(
libsyntax: Remove some more `@fn`s from the macro expander
2013-08-30 14:40:05 -07:00
ext::source_util::expand_include_str));
Rename include_bin! to include_bytes! According to [RFC 344][], methods that return `&[u8]` should have names ending in `bytes`. Though `include_bin!` is a macro not a method, it seems reasonable to follow the convention anyway. We keep the old name around for now, but trigger a deprecation warning when it is used. [RFC 344]: https://github.com/rust-lang/rfcs/blob/master/text/0344-conventions-galore.md [breaking-change]
2014-12-22 10:57:09 +13:00
syntax_expanders.insert(intern("include_bytes"),
builtin_normal_expander(
ext::source_util::expand_include_bytes));
librustc: Remove `~"string"` and `&"string"` from the language
2014-04-30 16:49:12 -07:00
syntax_expanders.insert(intern("module_path"),
Simplify and rename macro API Now that procedural macros can be implemented outside of the compiler, it's more important to have a reasonable API to work with. Here are the basic changes: * Rename SyntaxExpanderTTTrait to MacroExpander, SyntaxExpanderTT to BasicMacroExpander, etc. I think "procedural macro" is the right term for these now, right? The other option would be SynExtExpander or something like that. * Stop passing the SyntaxContext to extensions. This was only ever used by macro_rules, which doesn't even use it anymore. I can't think of a context in which an external extension would need it, and removal allows the API to be significantly simpler - no more SyntaxExpanderTTItemExpanderWithoutContext wrappers to worry about.
2014-01-25 13:34:26 -08:00
builtin_normal_expander(
libsyntax: Remove some more `@fn`s from the macro expander
2013-08-30 14:40:05 -07:00
ext::source_util::expand_mod));
librustc: Remove `~"string"` and `&"string"` from the language
2014-04-30 16:49:12 -07:00
syntax_expanders.insert(intern("asm"),
Simplify and rename macro API Now that procedural macros can be implemented outside of the compiler, it's more important to have a reasonable API to work with. Here are the basic changes: * Rename SyntaxExpanderTTTrait to MacroExpander, SyntaxExpanderTT to BasicMacroExpander, etc. I think "procedural macro" is the right term for these now, right? The other option would be SynExtExpander or something like that. * Stop passing the SyntaxContext to extensions. This was only ever used by macro_rules, which doesn't even use it anymore. I can't think of a context in which an external extension would need it, and removal allows the API to be significantly simpler - no more SyntaxExpanderTTItemExpanderWithoutContext wrappers to worry about.
2014-01-25 13:34:26 -08:00
builtin_normal_expander(
libsyntax: Remove some more `@fn`s from the macro expander
2013-08-30 14:40:05 -07:00
ext::asm::expand_asm));
librustc: Remove `~"string"` and `&"string"` from the language
2014-04-30 16:49:12 -07:00
syntax_expanders.insert(intern("cfg"),
Simplify and rename macro API Now that procedural macros can be implemented outside of the compiler, it's more important to have a reasonable API to work with. Here are the basic changes: * Rename SyntaxExpanderTTTrait to MacroExpander, SyntaxExpanderTT to BasicMacroExpander, etc. I think "procedural macro" is the right term for these now, right? The other option would be SynExtExpander or something like that. * Stop passing the SyntaxContext to extensions. This was only ever used by macro_rules, which doesn't even use it anymore. I can't think of a context in which an external extension would need it, and removal allows the API to be significantly simpler - no more SyntaxExpanderTTItemExpanderWithoutContext wrappers to worry about.
2014-01-25 13:34:26 -08:00
builtin_normal_expander(
libsyntax: Remove some more `@fn`s from the macro expander
2013-08-30 14:40:05 -07:00
ext::cfg::expand_cfg));
librustc: Remove `~"string"` and `&"string"` from the language
2014-04-30 16:49:12 -07:00
syntax_expanders.insert(intern("trace_macros"),
Simplify and rename macro API Now that procedural macros can be implemented outside of the compiler, it's more important to have a reasonable API to work with. Here are the basic changes: * Rename SyntaxExpanderTTTrait to MacroExpander, SyntaxExpanderTT to BasicMacroExpander, etc. I think "procedural macro" is the right term for these now, right? The other option would be SynExtExpander or something like that. * Stop passing the SyntaxContext to extensions. This was only ever used by macro_rules, which doesn't even use it anymore. I can't think of a context in which an external extension would need it, and removal allows the API to be significantly simpler - no more SyntaxExpanderTTItemExpanderWithoutContext wrappers to worry about.
2014-01-25 13:34:26 -08:00
builtin_normal_expander(
libsyntax: Remove some more `@fn`s from the macro expander
2013-08-30 14:40:05 -07:00
ext::trace_macros::expand_trace_macros));
Rewrite SyntaxEnv I'd really like to be able to do something like struct MapChain<'next, K, V> { info: BlockInfo, map: HashMap<K, V>, next: Option<&'next mut MapChain<'next, K, V> } but I can't get the lifetimes to work out.
2013-12-30 17:45:39 -08:00
syntax_expanders
remove the old auto_serialize syntax extension
2012-10-07 14:56:18 -07:00
}
Comments in the new macro system, reflecting conversation with pauls.
2012-07-27 17:42:32 -07:00
syntax: doc comments all the things
2014-06-09 13:12:30 -07:00
/// One of these is made during expansion and incrementally updated as we go;
/// when a macro expansion occurs, the resulting nodes have the backtrace()
/// -> expn_info of their expansion context stored into their span.
Load macros from external modules
2013-12-25 11:10:33 -07:00
pub struct ExtCtxt<'a> {
syntax: Switch field privacy as necessary
2014-03-27 15:39:48 -07:00
pub parse_sess: &'a parse::ParseSess,
pub cfg: ast::CrateConfig,
syntax: use an index in CodeMap instead of Gc for ExpnInfo.
2014-09-17 19:01:33 +03:00
pub backtrace: ExpnId,
libsyntax: Pass feature set in ExpansionConfig, not just enable_quotes.
2015-02-15 21:30:45 +01:00
pub ecfg: expand::ExpansionConfig<'a>,
Don't use std:: paths in syntax extensions when compiling a #![no_std] crate Fixes #16803. Fixes #14342. Fixes half of #21827 -- slice syntax is still broken.
2014-09-07 14:57:26 -07:00
pub use_std: bool,
Make #fmt work from inside std. Issue #175 At long last, this patch makes #fmt usable from inside the standard library. The way it does it us very hackish, but at least it works now.
2011-07-10 17:00:28 -07:00
syntax: Switch field privacy as necessary
2014-03-27 15:39:48 -07:00
pub mod_path: Vec<ast::Ident> ,
pub trace_mac: bool,
Reformat metadata for exported macros Instead of copy-pasting the whole macro_rules! item from the original .rs file, we serialize a separate name, attributes list, and body, the latter as pretty-printed TTs. The compilation of macro_rules! macros is decoupled somewhat from the expansion of macros in item position. This filters out comments, and facilitates selective imports.
2014-12-30 19:10:46 -08:00
pub exported_macros: Vec<ast::MacroDef>,
Moved `syntax::ext::base::SyntaxEnv` into `syntax::ext::base::ExtCtx`
2014-07-19 21:34:24 +02:00
Refactoring: Only use `MacroExpander` for expanding outside of `syntax::ext::expand`
2014-07-20 16:25:35 +02:00
pub syntax_env: SyntaxEnv,
libsyntax: uint types to usize
2015-01-17 23:33:05 +00:00
pub recursion_count: usize,
syntax/ext: Remove the trait-object indirection of the ext_ctxt object.
2013-05-17 20:10:26 +10:00
}
new borrow checker (mass squash)
2013-03-15 15:24:24 -04:00
Load macros from external modules
2013-12-25 11:10:33 -07:00
impl<'a> ExtCtxt<'a> {
Remove all shadowed lifetimes.
2014-12-12 11:09:32 -05:00
pub fn new(parse_sess: &'a parse::ParseSess, cfg: ast::CrateConfig,
libsyntax: Pass feature set in ExpansionConfig, not just enable_quotes.
2015-02-15 21:30:45 +01:00
ecfg: expand::ExpansionConfig<'a>) -> ExtCtxt<'a> {
Hide the quote_*! macros when the feature gate is off This makes it easier to experiment with improved quasiquoting as an ordinary plugin library. The list of quote macros in feature_gate.rs was already out of sync; this commit also prevents that problem in the future.
2014-09-26 17:14:23 -07:00
let env = initial_syntax_expander_table(&ecfg);
Stop using @ExtCtxt
2013-12-27 17:17:36 -07:00
ExtCtxt {
syntax/ext: modernise ext_ctxt to be CamelCase and use new.
2013-05-17 21:27:17 +10:00
parse_sess: parse_sess,
cfg: cfg,
syntax: use an index in CodeMap instead of Gc for ExpnInfo.
2014-09-17 19:01:33 +03:00
backtrace: NO_EXPANSION,
libsyntax: Mechanically change `~[T]` to `Vec<T>`
2014-02-28 13:09:09 -08:00
mod_path: Vec::new(),
syntax: Conditionally deriving(Hash) with Writers If #[feature(default_type_parameters)] is enabled for a crate, then deriving(Hash) will expand with Hash<W: Writer> instead of Hash<SipState> so more hash algorithms can be used.
2014-02-28 23:17:38 -08:00
ecfg: ecfg,
Don't use std:: paths in syntax extensions when compiling a #![no_std] crate Fixes #16803. Fixes #14342. Fixes half of #21827 -- slice syntax is still broken.
2014-09-07 14:57:26 -07:00
use_std: true,
use side table to store exported macros Per discussion with @sfackler, refactored the expander to change the way that exported macros are collected. Specifically, a crate now contains a side table of spans that exported macros go into. This has two benefits. First, the encoder doesn't need to scan through the expanded crate in order to discover exported macros. Second, the expander can drop all expanded macros from the crate, with the pleasant result that a fully expanded crate contains no macro invocations (which include macro definitions).
2014-07-10 15:41:11 -07:00
trace_mac: false,
exported_macros: Vec::new(),
Hide the quote_*! macros when the feature gate is off This makes it easier to experiment with improved quasiquoting as an ordinary plugin library. The list of quote macros in feature_gate.rs was already out of sync; this commit also prevents that problem in the future.
2014-09-26 17:14:23 -07:00
syntax_env: env,
Limit recursion depth for macro expansions, closes #17628
2014-10-01 11:38:54 +02:00
recursion_count: 0,
syntax/ext: modernise ext_ctxt to be CamelCase and use new.
2013-05-17 21:27:17 +10:00
}
}
Deprecated attributes don't take 'feature' names and are paired with stable/unstable Conflicts: src/libcore/atomic.rs src/libcore/finally.rs src/test/auxiliary/inherited_stability.rs src/test/auxiliary/lint_stability.rs
2015-01-22 12:33:46 -08:00
#[unstable(feature = "rustc_private")]
#[deprecated(since = "1.0.0",
Add 'feature' and 'since' to stability attributes
2015-01-12 18:40:19 -08:00
reason = "Replaced with `expander().fold_expr()`")]
syntax: fix fallout from using ptr::P.
2014-09-13 19:06:01 +03:00
pub fn expand_expr(&mut self, e: P<ast::Expr>) -> P<ast::Expr> {
Refactoring: Only use `MacroExpander` for expanding outside of `syntax::ext::expand`
2014-07-20 16:25:35 +02:00
self.expander().fold_expr(e)
}
/// Returns a `Folder` for deeply expanding all macros in a AST node.
pub fn expander<'b>(&'b mut self) -> expand::MacroExpander<'b, 'a> {
Allow `Self` in impls.
2014-12-14 15:42:41 +13:00
expand::MacroExpander::new(self)
Implement a concat!() format extension This extension can be used to concatenate string literals at compile time. C has this useful ability when placing string literals lexically next to one another, but this needs to be handled at the syntax extension level to recursively expand macros. The major use case for this is something like: macro_rules! mylog( ($fmt:expr $($arg:tt)*) => { error2!(concat!(file!(), ":", line!(), " - ", $fmt) $($arg)*); }) Where the mylog macro will automatically prepend the filename/line number to the beginning of every log message.
2013-10-05 21:15:46 -07:00
}
Simplify creating a parser from a token tree Closes #15306
2014-07-03 11:42:24 +02:00
pub fn new_parser_from_tts(&self, tts: &[ast::TokenTree])
-> parser::Parser<'a> {
Remove a large amount of deprecated functionality Spring cleaning is here! In the Fall! This commit removes quite a large amount of deprecated functionality from the standard libraries. I tried to ensure that only old deprecated functionality was removed. This is removing lots and lots of deprecated features, so this is a breaking change. Please consult the deprecation messages of the deleted code to see how to migrate code forward if it still needs migration. [breaking-change]
2014-10-14 23:05:01 -07:00
parse::tts_to_parser(self.parse_sess, tts.to_vec(), self.cfg())
Simplify creating a parser from a token tree Closes #15306
2014-07-03 11:42:24 +02:00
}
De-@ codemap and diagnostic.
2014-03-16 20:56:24 +02:00
pub fn codemap(&self) -> &'a CodeMap { &self.parse_sess.span_diagnostic.cm }
De-@ ParseSess uses.
2014-03-09 16:54:34 +02:00
pub fn parse_sess(&self) -> &'a parse::ParseSess { self.parse_sess }
Ast spanned<T> refactoring, renaming: crate, local, blk, crate_num, crate_cfg. `crate => Crate` `local => Local` `blk => Block` `crate_num => CrateNum` `crate_cfg => CrateConfig` Also, Crate and Local are not wrapped in spanned<T> anymore.
2013-07-19 07:38:55 +02:00
pub fn cfg(&self) -> ast::CrateConfig { self.cfg.clone() }
Modernized a few type names in rustc and syntax
2013-08-31 18:13:04 +02:00
pub fn call_site(&self) -> Span {
syntax: use an index in CodeMap instead of Gc for ExpnInfo.
2014-09-17 19:01:33 +03:00
self.codemap().with_expn_info(self.backtrace, |ei| match ei {
librustc: Remove `@` pointer patterns from the language
2014-01-03 15:08:48 -08:00
Some(expn_info) => expn_info.call_site,
syntax/ext: Remove the trait-object indirection of the ext_ctxt object.
2013-05-17 20:10:26 +10:00
None => self.bug("missing top span")
syntax: use an index in CodeMap instead of Gc for ExpnInfo.
2014-09-17 19:01:33 +03:00
})
syntax/ext: Remove the trait-object indirection of the ext_ctxt object.
2013-05-17 20:10:26 +10:00
}
Remove all uses of `pub impl`. rs=style
2013-05-31 15:17:22 -07:00
pub fn print_backtrace(&self) { }
syntax: use an index in CodeMap instead of Gc for ExpnInfo.
2014-09-17 19:01:33 +03:00
pub fn backtrace(&self) -> ExpnId { self.backtrace }
pub fn original_span(&self) -> Span {
let mut expn_id = self.backtrace;
let mut call_site = None;
loop {
match self.codemap().with_expn_info(expn_id, |ei| ei.map(|ei| ei.call_site)) {
None => break,
Some(cs) => {
call_site = Some(cs);
expn_id = cs.expn_id;
}
}
}
call_site.expect("missing expansion backtrace")
}
pub fn original_span_in_file(&self) -> Span {
let mut expn_id = self.backtrace;
let mut call_site = None;
loop {
let expn_info = self.codemap().with_expn_info(expn_id, |ei| {
libsyntax: remove unnecessary `as_slice()` calls
2014-11-27 15:00:50 -05:00
ei.map(|ei| (ei.call_site, ei.callee.name == "include"))
syntax: use an index in CodeMap instead of Gc for ExpnInfo.
2014-09-17 19:01:33 +03:00
});
match expn_info {
None => break,
Some((cs, is_include)) => {
if is_include {
// Don't recurse into file using "include!".
break;
}
call_site = Some(cs);
expn_id = cs.expn_id;
}
}
}
call_site.expect("missing expansion backtrace")
}
Remove @muts from ExtCtxt
2013-12-28 22:35:38 -07:00
pub fn mod_push(&mut self, i: ast::Ident) { self.mod_path.push(i); }
[std::vec] Rename .pop_opt() to .pop(), drop the old .pop() behavior
2013-12-23 16:20:52 +01:00
pub fn mod_pop(&mut self) { self.mod_path.pop().unwrap(); }
log: Introduce liblog, the old std::logging This commit moves all logging out of the standard library into an external crate. This crate is the new crate which is responsible for all logging macros and logging implementation. A few reasons for this change are: * The crate map has always been a bit of a code smell among rust programs. It has difficulty being loaded on almost all platforms, and it's used almost exclusively for logging and only logging. Removing the crate map is one of the end goals of this movement. * The compiler has a fair bit of special support for logging. It has the __log_level() expression as well as generating a global word per module specifying the log level. This is unfairly favoring the built-in logging system, and is much better done purely in libraries instead of the compiler itself. * Initialization of logging is much easier to do if there is no reliance on a magical crate map being available to set module log levels. * If the logging library can be written outside of the standard library, there's no reason that it shouldn't be. It's likely that we're not going to build the highest quality logging library of all time, so third-party libraries should be able to provide just as high-quality logging systems as the default one provided in the rust distribution. With a migration such as this, the change does not come for free. There are some subtle changes in the behavior of liblog vs the previous logging macros: * The core change of this migration is that there is no longer a physical log-level per module. This concept is still emulated (it is quite useful), but there is now only a global log level, not a local one. This global log level is a reflection of the maximum of all log levels specified. The previously generated logging code looked like: if specified_level <= __module_log_level() { println!(...) } The newly generated code looks like: if specified_level <= ::log::LOG_LEVEL { if ::log::module_enabled(module_path!()) { println!(...) } } Notably, the first layer of checking is still intended to be "super fast" in that it's just a load of a global word and a compare. The second layer of checking is executed to determine if the current module does indeed have logging turned on. This means that if any module has a debug log level turned on, all modules with debug log levels get a little bit slower (they all do more expensive dynamic checks to determine if they're turned on or not). Semantically, this migration brings no change in this respect, but runtime-wise, this will have a perf impact on some code. * A `RUST_LOG=::help` directive will no longer print out a list of all modules that can be logged. This is because the crate map will no longer specify the log levels of all modules, so the list of modules is not known. Additionally, warnings can no longer be provided if a malformed logging directive was supplied. The new "hello world" for logging looks like: #[phase(syntax, link)] extern crate log; fn main() { debug!("Hello, world!"); }
2014-03-08 22:11:44 -08:00
pub fn mod_path(&self) -> Vec<ast::Ident> {
let mut v = Vec::new();
Remove remaining uses of `[]`. This time I tried to use deref coercions where possible.
2015-02-20 14:08:14 -05:00
v.push(token::str_to_ident(&self.ecfg.crate_name));
Opt for .cloned() over .map(|x| x.clone()) etc.
2015-02-13 07:33:44 +00:00
v.extend(self.mod_path.iter().cloned());
log: Introduce liblog, the old std::logging This commit moves all logging out of the standard library into an external crate. This crate is the new crate which is responsible for all logging macros and logging implementation. A few reasons for this change are: * The crate map has always been a bit of a code smell among rust programs. It has difficulty being loaded on almost all platforms, and it's used almost exclusively for logging and only logging. Removing the crate map is one of the end goals of this movement. * The compiler has a fair bit of special support for logging. It has the __log_level() expression as well as generating a global word per module specifying the log level. This is unfairly favoring the built-in logging system, and is much better done purely in libraries instead of the compiler itself. * Initialization of logging is much easier to do if there is no reliance on a magical crate map being available to set module log levels. * If the logging library can be written outside of the standard library, there's no reason that it shouldn't be. It's likely that we're not going to build the highest quality logging library of all time, so third-party libraries should be able to provide just as high-quality logging systems as the default one provided in the rust distribution. With a migration such as this, the change does not come for free. There are some subtle changes in the behavior of liblog vs the previous logging macros: * The core change of this migration is that there is no longer a physical log-level per module. This concept is still emulated (it is quite useful), but there is now only a global log level, not a local one. This global log level is a reflection of the maximum of all log levels specified. The previously generated logging code looked like: if specified_level <= __module_log_level() { println!(...) } The newly generated code looks like: if specified_level <= ::log::LOG_LEVEL { if ::log::module_enabled(module_path!()) { println!(...) } } Notably, the first layer of checking is still intended to be "super fast" in that it's just a load of a global word and a compare. The second layer of checking is executed to determine if the current module does indeed have logging turned on. This means that if any module has a debug log level turned on, all modules with debug log levels get a little bit slower (they all do more expensive dynamic checks to determine if they're turned on or not). Semantically, this migration brings no change in this respect, but runtime-wise, this will have a perf impact on some code. * A `RUST_LOG=::help` directive will no longer print out a list of all modules that can be logged. This is because the crate map will no longer specify the log levels of all modules, so the list of modules is not known. Additionally, warnings can no longer be provided if a malformed logging directive was supplied. The new "hello world" for logging looks like: #[phase(syntax, link)] extern crate log; fn main() { debug!("Hello, world!"); }
2014-03-08 22:11:44 -08:00
return v;
}
syntax: use an index in CodeMap instead of Gc for ExpnInfo.
2014-09-17 19:01:33 +03:00
pub fn bt_push(&mut self, ei: ExpnInfo) {
Limit recursion depth for macro expansions, closes #17628
2014-10-01 11:38:54 +02:00
self.recursion_count += 1;
if self.recursion_count > self.ecfg.recursion_limit {
self.span_fatal(ei.call_site,
use slicing sugar
2015-01-07 11:58:31 -05:00
&format!("recursion limit reached while expanding the macro `{}`",
Remove remaining uses of `[]`. This time I tried to use deref coercions where possible.
2015-02-20 14:08:14 -05:00
ei.callee.name));
Limit recursion depth for macro expansions, closes #17628
2014-10-01 11:38:54 +02:00
}
syntax: use an index in CodeMap instead of Gc for ExpnInfo.
2014-09-17 19:01:33 +03:00
let mut call_site = ei.call_site;
call_site.expn_id = self.backtrace;
self.backtrace = self.codemap().record_expansion(ExpnInfo {
call_site: call_site,
callee: ei.callee
});
syntax/ext: Remove the trait-object indirection of the ext_ctxt object.
2013-05-17 20:10:26 +10:00
}
Remove @muts from ExtCtxt
2013-12-28 22:35:38 -07:00
pub fn bt_pop(&mut self) {
match self.backtrace {
syntax: use an index in CodeMap instead of Gc for ExpnInfo.
2014-09-17 19:01:33 +03:00
NO_EXPANSION => self.bug("tried to pop without a push"),
expn_id => {
Limit recursion depth for macro expansions, closes #17628
2014-10-01 11:38:54 +02:00
self.recursion_count -= 1;
syntax: use an index in CodeMap instead of Gc for ExpnInfo.
2014-09-17 19:01:33 +03:00
self.backtrace = self.codemap().with_expn_info(expn_id, |expn_info| {
expn_info.map_or(NO_EXPANSION, |ei| ei.call_site.expn_id)
});
}
Remove all remaining uses of objs from the compiler
2012-01-13 09:32:05 +01:00
}
}
Move #[macro_reexport] to extern crate
2015-01-01 16:37:47 -08:00
pub fn insert_macro(&mut self, def: ast::MacroDef) {
if def.export {
self.exported_macros.push(def.clone());
}
Allow selective macro import
2015-01-02 12:50:45 -08:00
if def.use_locally {
let ext = macro_rules::compile(self, &def);
self.syntax_env.insert(def.ident.name, ext);
}
Move #[macro_reexport] to extern crate
2015-01-01 16:37:47 -08:00
}
syntax::ext: replace span_fatal with span_err in many places. This means that compilation continues for longer, and so we can see more errors per compile. This is mildly more user-friendly because it stops users having to run rustc n times to see n macro errors: just run it once to see all of them.
2014-01-18 01:53:10 +11:00
/// Emit `msg` attached to `sp`, and stop compilation immediately.
///
Fix spelling errors.
2014-07-02 21:27:07 -04:00
/// `span_err` should be strongly preferred where-ever possible:
syntax::ext: replace span_fatal with span_err in many places. This means that compilation continues for longer, and so we can see more errors per compile. This is mildly more user-friendly because it stops users having to run rustc n times to see n macro errors: just run it once to see all of them.
2014-01-18 01:53:10 +11:00
/// this should *only* be used when
/// - continuing has a high risk of flow-on errors (e.g. errors in
/// declaring a macro would cause all uses of that macro to
/// complain about "undefined macro"), or
/// - there is literally nothing else that can be done (however,
/// in most cases one can construct a dummy expression/item to
/// substitute; we never hit resolve/type-checking so the dummy
/// value doesn't have to match anything)
Modernized a few type names in rustc and syntax
2013-08-31 18:13:04 +02:00
pub fn span_fatal(&self, sp: Span, msg: &str) -> ! {
syntax/ext: Remove the trait-object indirection of the ext_ctxt object.
2013-05-17 20:10:26 +10:00
self.print_backtrace();
self.parse_sess.span_diagnostic.span_fatal(sp, msg);
}
syntax::ext: replace span_fatal with span_err in many places. This means that compilation continues for longer, and so we can see more errors per compile. This is mildly more user-friendly because it stops users having to run rustc n times to see n macro errors: just run it once to see all of them.
2014-01-18 01:53:10 +11:00
/// Emit `msg` attached to `sp`, without immediately stopping
/// compilation.
///
/// Compilation will be stopped in the near future (at the end of
/// the macro expansion phase).
Modernized a few type names in rustc and syntax
2013-08-31 18:13:04 +02:00
pub fn span_err(&self, sp: Span, msg: &str) {
syntax/ext: Remove the trait-object indirection of the ext_ctxt object.
2013-05-17 20:10:26 +10:00
self.print_backtrace();
self.parse_sess.span_diagnostic.span_err(sp, msg);
}
Modernized a few type names in rustc and syntax
2013-08-31 18:13:04 +02:00
pub fn span_warn(&self, sp: Span, msg: &str) {
syntax/ext: Remove the trait-object indirection of the ext_ctxt object.
2013-05-17 20:10:26 +10:00
self.print_backtrace();
self.parse_sess.span_diagnostic.span_warn(sp, msg);
}
Modernized a few type names in rustc and syntax
2013-08-31 18:13:04 +02:00
pub fn span_unimpl(&self, sp: Span, msg: &str) -> ! {
syntax/ext: Remove the trait-object indirection of the ext_ctxt object.
2013-05-17 20:10:26 +10:00
self.print_backtrace();
self.parse_sess.span_diagnostic.span_unimpl(sp, msg);
}
Modernized a few type names in rustc and syntax
2013-08-31 18:13:04 +02:00
pub fn span_bug(&self, sp: Span, msg: &str) -> ! {
syntax/ext: Remove the trait-object indirection of the ext_ctxt object.
2013-05-17 20:10:26 +10:00
self.print_backtrace();
self.parse_sess.span_diagnostic.span_bug(sp, msg);
}
Add span_note to ExtCtxt It was the only span_* missing.
2014-01-19 11:24:27 -08:00
pub fn span_note(&self, sp: Span, msg: &str) {
self.print_backtrace();
self.parse_sess.span_diagnostic.span_note(sp, msg);
}
Add help diagnostic messages This adds ‘help’ diagnostic messages to rustc. This is used for anything that provides help to the user, particularly the `--explain` messages that were previously integrated into the relevant error message.
2014-08-29 18:55:35 +12:00
pub fn span_help(&self, sp: Span, msg: &str) {
self.print_backtrace();
self.parse_sess.span_diagnostic.span_help(sp, msg);
}
Change span_help calls to fileline_help where appropriate
2015-02-24 16:07:54 +02:00
pub fn fileline_help(&self, sp: Span, msg: &str) {
self.print_backtrace();
self.parse_sess.span_diagnostic.fileline_help(sp, msg);
}
Remove all uses of `pub impl`. rs=style
2013-05-31 15:17:22 -07:00
pub fn bug(&self, msg: &str) -> ! {
syntax/ext: Remove the trait-object indirection of the ext_ctxt object.
2013-05-17 20:10:26 +10:00
self.print_backtrace();
self.parse_sess.span_diagnostic.handler().bug(msg);
}
Remove all uses of `pub impl`. rs=style
2013-05-31 15:17:22 -07:00
pub fn trace_macros(&self) -> bool {
Remove @muts from ExtCtxt
2013-12-28 22:35:38 -07:00
self.trace_mac
syntax/ext: Remove the trait-object indirection of the ext_ctxt object.
2013-05-17 20:10:26 +10:00
}
Remove @muts from ExtCtxt
2013-12-28 22:35:38 -07:00
pub fn set_trace_macros(&mut self, x: bool) {
self.trace_mac = x
syntax/ext: Remove the trait-object indirection of the ext_ctxt object.
2013-05-17 20:10:26 +10:00
}
Renamed syntax::ast::ident -> Ident
2013-09-02 02:50:59 +02:00
pub fn ident_of(&self, st: &str) -> ast::Ident {
interner just uses uints, not idents with syntax context
2013-06-04 12:34:25 -07:00
str_to_ident(st)
syntax/ext: Remove the trait-object indirection of the ext_ctxt object.
2013-05-17 20:10:26 +10:00
}
Don't use std:: paths in syntax extensions when compiling a #![no_std] crate Fixes #16803. Fixes #14342. Fixes half of #21827 -- slice syntax is still broken.
2014-09-07 14:57:26 -07:00
pub fn ident_of_std(&self, st: &str) -> ast::Ident {
self.ident_of(if self.use_std { "std" } else { st })
}
ast: make Name its own type
2014-07-06 01:17:59 -07:00
pub fn name_of(&self, st: &str) -> ast::Name {
token::intern(st)
}
syntax/ext: Remove the trait-object indirection of the ext_ctxt object.
2013-05-17 20:10:26 +10:00
}
Expand string literals and exprs inside of macros A couple of syntax extensions manually expanded expressions, but it wasn't done universally, most noticably inside of asm!(). There's also a bit of random cleanup.
2014-03-02 13:38:44 -08:00
/// Extract a string literal from the macro expanded version of `expr`,
/// emitting `err_msg` if `expr` is not a string literal. This does not stop
/// compilation on error, merely emits a non-fatal error and returns None.
syntax: fix fallout from using ptr::P.
2014-09-13 19:06:01 +03:00
pub fn expr_to_string(cx: &mut ExtCtxt, expr: P<ast::Expr>, err_msg: &str)
-> Option<(InternedString, ast::StrStyle)> {
Expand string literals and exprs inside of macros A couple of syntax extensions manually expanded expressions, but it wasn't done universally, most noticably inside of asm!(). There's also a bit of random cleanup.
2014-03-02 13:38:44 -08:00
// we want to be able to handle e.g. concat("foo", "bar")
Refactoring: Only use `MacroExpander` for expanding outside of `syntax::ext::expand`
2014-07-20 16:25:35 +02:00
let expr = cx.expander().fold_expr(expr);
Convert alt to match. Stop parsing alt
2012-08-06 12:34:08 -07:00
match expr.node {
syntax: fix fallout from using ptr::P.
2014-09-13 19:06:01 +03:00
ast::ExprLit(ref l) => match l.node {
librustc: Fix merge fallout.
2014-01-21 10:08:10 -08:00
ast::LitStr(ref s, style) => return Some(((*s).clone(), style)),
syntax::ext: replace span_fatal with span_err in many places. This means that compilation continues for longer, and so we can see more errors per compile. This is mildly more user-friendly because it stops users having to run rustc n times to see n macro errors: just run it once to see all of them.
2014-01-18 01:53:10 +11:00
_ => cx.span_err(l.span, err_msg)
libsyntax: Renamed types, traits and enum variants to CamelCase.
2014-01-09 15:05:33 +02:00
},
syntax::ext: replace span_fatal with span_err in many places. This means that compilation continues for longer, and so we can see more errors per compile. This is mildly more user-friendly because it stops users having to run rustc n times to see n macro errors: just run it once to see all of them.
2014-01-18 01:53:10 +11:00
_ => cx.span_err(expr.span, err_msg)
Add simple syntax extension (#simplext)
2011-06-20 17:26:17 -07:00
}
syntax::ext: replace span_fatal with span_err in many places. This means that compilation continues for longer, and so we can see more errors per compile. This is mildly more user-friendly because it stops users having to run rustc n times to see n macro errors: just run it once to see all of them.
2014-01-18 01:53:10 +11:00
None
Add simple syntax extension (#simplext)
2011-06-20 17:26:17 -07:00
}
syntax::ext: replace span_fatal with span_err in many places. This means that compilation continues for longer, and so we can see more errors per compile. This is mildly more user-friendly because it stops users having to run rustc n times to see n macro errors: just run it once to see all of them.
2014-01-18 01:53:10 +11:00
/// Non-fatally assert that `tts` is empty. Note that this function
/// returns even when `tts` is non-empty, macros that *need* to stop
/// compilation should call
/// `cx.parse_sess.span_diagnostic.abort_if_errors()` (this should be
/// done as rarely as possible).
libsyntax: De-`@str` literal strings in the AST
2014-01-10 14:02:36 -08:00
pub fn check_zero_tts(cx: &ExtCtxt,
sp: Span,
tts: &[ast::TokenTree],
libsyntax: De-export libsyntax. rs=deexporting
2013-01-29 14:41:40 -08:00
name: &str) {
syntax: remove remaining #syntaxext machinery. Close #3516.
2012-12-12 17:08:09 -08:00
if tts.len() != 0 {
Remove remaining uses of `[]`. This time I tried to use deref coercions where possible.
2015-02-20 14:08:14 -05:00
cx.span_err(sp, &format!("{} takes no arguments", name));
syntax: remove remaining #syntaxext machinery. Close #3516.
2012-12-12 17:08:09 -08:00
}
Make extracting syntax extension arguments easier.
2012-05-14 15:32:32 -07:00
}
syntax::ext: replace span_fatal with span_err in many places. This means that compilation continues for longer, and so we can see more errors per compile. This is mildly more user-friendly because it stops users having to run rustc n times to see n macro errors: just run it once to see all of them.
2014-01-18 01:53:10 +11:00
/// Extract the string literal from the first token of `tts`. If this
/// is not a string literal, emit an error and return None.
rustc: Implement -l and include! tweaks This is an implementation of the rustc bits of [RFC 403][rfc]. This adds a new flag to the compiler, `-l`, as well as tweaking the `include!` macro (and related source-centric macros). The compiler's new `-l` flag is used to link libraries in from the command line. This flag stacks with `#[link]` directives already found in the program. The purpose of this flag, also stated in the RFC, is to ease linking against native libraries which have wildly different requirements across platforms and even within distributions of one platform. This flag accepts a string of the form `NAME[:KIND]` where `KIND` is optional or one of dylib, static, or framework. This is roughly equivalent to if the equivalent `#[link]` directive were just written in the program. The `include!` macro has been modified to recursively expand macros to allow usage of `concat!` as an argument, for example. The use case spelled out in RFC 403 was for `env!` to be used as well to include compile-time generated files. The macro also received a bit of tweaking to allow it to expand to either an expression or a series of items, depending on what context it's used in. [rfc]: https://github.com/rust-lang/rfcs/pull/403
2014-10-20 23:04:16 -07:00
pub fn get_single_str_from_tts(cx: &mut ExtCtxt,
Modernized a few type names in rustc and syntax
2013-08-31 18:13:04 +02:00
sp: Span,
libsyntax: Renamed types, traits and enum variants to CamelCase.
2014-01-09 15:05:33 +02:00
tts: &[ast::TokenTree],
librustc: Add support for type parameters in the middle of paths. For example, `foo::<T>::bar::<U>`. This doesn't enforce that the type parameters are in the right positions, however.
2013-08-07 09:47:28 -07:00
name: &str)
core: rename strbuf::StrBuf to string::String [breaking-change]
2014-05-22 16:57:53 -07:00
-> Option<String> {
rustc: Implement -l and include! tweaks This is an implementation of the rustc bits of [RFC 403][rfc]. This adds a new flag to the compiler, `-l`, as well as tweaking the `include!` macro (and related source-centric macros). The compiler's new `-l` flag is used to link libraries in from the command line. This flag stacks with `#[link]` directives already found in the program. The purpose of this flag, also stated in the RFC, is to ease linking against native libraries which have wildly different requirements across platforms and even within distributions of one platform. This flag accepts a string of the form `NAME[:KIND]` where `KIND` is optional or one of dylib, static, or framework. This is roughly equivalent to if the equivalent `#[link]` directive were just written in the program. The `include!` macro has been modified to recursively expand macros to allow usage of `concat!` as an argument, for example. The use case spelled out in RFC 403 was for `env!` to be used as well to include compile-time generated files. The macro also received a bit of tweaking to allow it to expand to either an expression or a series of items, depending on what context it's used in. [rfc]: https://github.com/rust-lang/rfcs/pull/403
2014-10-20 23:04:16 -07:00
let mut p = cx.new_parser_from_tts(tts);
Test fixes and rebase conflicts
2014-11-02 23:10:09 -08:00
if p.token == token::Eof {
Remove remaining uses of `[]`. This time I tried to use deref coercions where possible.
2015-02-20 14:08:14 -05:00
cx.span_err(sp, &format!("{} takes 1 argument", name));
Test fixes and rebase conflicts
2014-11-02 23:10:09 -08:00
return None
}
rustc: Implement -l and include! tweaks This is an implementation of the rustc bits of [RFC 403][rfc]. This adds a new flag to the compiler, `-l`, as well as tweaking the `include!` macro (and related source-centric macros). The compiler's new `-l` flag is used to link libraries in from the command line. This flag stacks with `#[link]` directives already found in the program. The purpose of this flag, also stated in the RFC, is to ease linking against native libraries which have wildly different requirements across platforms and even within distributions of one platform. This flag accepts a string of the form `NAME[:KIND]` where `KIND` is optional or one of dylib, static, or framework. This is roughly equivalent to if the equivalent `#[link]` directive were just written in the program. The `include!` macro has been modified to recursively expand macros to allow usage of `concat!` as an argument, for example. The use case spelled out in RFC 403 was for `env!` to be used as well to include compile-time generated files. The macro also received a bit of tweaking to allow it to expand to either an expression or a series of items, depending on what context it's used in. [rfc]: https://github.com/rust-lang/rfcs/pull/403
2014-10-20 23:04:16 -07:00
let ret = cx.expander().fold_expr(p.parse_expr());
if p.token != token::Eof {
Remove remaining uses of `[]`. This time I tried to use deref coercions where possible.
2015-02-20 14:08:14 -05:00
cx.span_err(sp, &format!("{} takes 1 argument", name));
Add support for recognizing macro body, completely untested.
2012-01-31 23:50:12 -07:00
}
rustc: Implement -l and include! tweaks This is an implementation of the rustc bits of [RFC 403][rfc]. This adds a new flag to the compiler, `-l`, as well as tweaking the `include!` macro (and related source-centric macros). The compiler's new `-l` flag is used to link libraries in from the command line. This flag stacks with `#[link]` directives already found in the program. The purpose of this flag, also stated in the RFC, is to ease linking against native libraries which have wildly different requirements across platforms and even within distributions of one platform. This flag accepts a string of the form `NAME[:KIND]` where `KIND` is optional or one of dylib, static, or framework. This is roughly equivalent to if the equivalent `#[link]` directive were just written in the program. The `include!` macro has been modified to recursively expand macros to allow usage of `concat!` as an argument, for example. The use case spelled out in RFC 403 was for `env!` to be used as well to include compile-time generated files. The macro also received a bit of tweaking to allow it to expand to either an expression or a series of items, depending on what context it's used in. [rfc]: https://github.com/rust-lang/rfcs/pull/403
2014-10-20 23:04:16 -07:00
expr_to_string(cx, ret, "argument must be a string literal").map(|(s, _)| {
Libsyntax has been updated
2015-02-03 23:31:06 +01:00
s.to_string()
rustc: Implement -l and include! tweaks This is an implementation of the rustc bits of [RFC 403][rfc]. This adds a new flag to the compiler, `-l`, as well as tweaking the `include!` macro (and related source-centric macros). The compiler's new `-l` flag is used to link libraries in from the command line. This flag stacks with `#[link]` directives already found in the program. The purpose of this flag, also stated in the RFC, is to ease linking against native libraries which have wildly different requirements across platforms and even within distributions of one platform. This flag accepts a string of the form `NAME[:KIND]` where `KIND` is optional or one of dylib, static, or framework. This is roughly equivalent to if the equivalent `#[link]` directive were just written in the program. The `include!` macro has been modified to recursively expand macros to allow usage of `concat!` as an argument, for example. The use case spelled out in RFC 403 was for `env!` to be used as well to include compile-time generated files. The macro also received a bit of tweaking to allow it to expand to either an expression or a series of items, depending on what context it's used in. [rfc]: https://github.com/rust-lang/rfcs/pull/403
2014-10-20 23:04:16 -07:00
})
Add support for recognizing macro body, completely untested.
2012-01-31 23:50:12 -07:00
}
Add simple syntax extension (#simplext)
2011-06-20 17:26:17 -07:00
syntax::ext: replace span_fatal with span_err in many places. This means that compilation continues for longer, and so we can see more errors per compile. This is mildly more user-friendly because it stops users having to run rustc n times to see n macro errors: just run it once to see all of them.
2014-01-18 01:53:10 +11:00
/// Extract comma-separated expressions from `tts`. If there is a
/// parsing error, emit a non-fatal error and return None.
Expand string literals and exprs inside of macros A couple of syntax extensions manually expanded expressions, but it wasn't done universally, most noticably inside of asm!(). There's also a bit of random cleanup.
2014-03-02 13:38:44 -08:00
pub fn get_exprs_from_tts(cx: &mut ExtCtxt,
Modernized a few type names in rustc and syntax
2013-08-31 18:13:04 +02:00
sp: Span,
syntax: fix fallout from using ptr::P.
2014-09-13 19:06:01 +03:00
tts: &[ast::TokenTree]) -> Option<Vec<P<ast::Expr>>> {
Simplify creating a parser from a token tree Closes #15306
2014-07-03 11:42:24 +02:00
let mut p = cx.new_parser_from_tts(tts);
libsyntax: Mechanically change `~[T]` to `Vec<T>`
2014-02-28 13:09:09 -08:00
let mut es = Vec::new();
Use PascalCase for token variants
2014-10-27 19:22:52 +11:00
while p.token != token::Eof {
Refactoring: Only use `MacroExpander` for expanding outside of `syntax::ext::expand`
2014-07-20 16:25:35 +02:00
es.push(cx.expander().fold_expr(p.parse_expr()));
Use PascalCase for token variants
2014-10-27 19:22:52 +11:00
if p.eat(&token::Comma) {
Allow trailing comma in `concat!` (And in other extensions implemented with `get_exprs_from_tts` function).
2014-06-23 15:51:40 +00:00
continue;
}
Use PascalCase for token variants
2014-10-27 19:22:52 +11:00
if p.token != token::Eof {
syntax::ext: replace span_fatal with span_err in many places. This means that compilation continues for longer, and so we can see more errors per compile. This is mildly more user-friendly because it stops users having to run rustc n times to see n macro errors: just run it once to see all of them.
2014-01-18 01:53:10 +11:00
cx.span_err(sp, "expected token: `,`");
return None;
syntax: remove remaining #syntaxext machinery. Close #3516.
2012-12-12 17:08:09 -08:00
}
Allow old-style syntax extensions to be called with new syntax.
2012-07-12 17:59:59 -07:00
}
syntax::ext: replace span_fatal with span_err in many places. This means that compilation continues for longer, and so we can see more errors per compile. This is mildly more user-friendly because it stops users having to run rustc n times to see n macro errors: just run it once to see all of them.
2014-01-18 01:53:10 +11:00
Some(es)
Allow old-style syntax extensions to be called with new syntax.
2012-07-12 17:59:59 -07:00
}
syntax: doc comments all the things
2014-06-09 13:12:30 -07:00
/// In order to have some notion of scoping for macros,
/// we want to implement the notion of a transformation
/// environment.
Moved `syntax::ext::base::SyntaxEnv` into `syntax::ext::base::ExtCtx`
2014-07-19 21:34:24 +02:00
///
syntax: doc comments all the things
2014-06-09 13:12:30 -07:00
/// This environment maps Names to SyntaxExtensions.
Moved `syntax::ext::base::SyntaxEnv` into `syntax::ext::base::ExtCtx`
2014-07-19 21:34:24 +02:00
pub struct SyntaxEnv {
chain: Vec<MapChainFrame> ,
}
Macros now leave scope Macro scope is now delimited by function, block, and module boundaries, except for modules that are marked with #[macro_escape], which allows macros to escape.
2013-02-26 10:15:29 -08:00
Moved `syntax::ext::base::SyntaxEnv` into `syntax::ext::base::ExtCtx`
2014-07-19 21:34:24 +02:00
// impl question: how to implement it? Initially, the
Macros now leave scope Macro scope is now delimited by function, block, and module boundaries, except for modules that are marked with #[macro_escape], which allows macros to escape.
2013-02-26 10:15:29 -08:00
// env will contain only macros, so it might be painful
// to add an empty frame for every context. Let's just
// get it working, first....
// NB! the mutability of the underlying maps means that
// if expansion is out-of-order, a deeper scope may be
// able to refer to a macro that was added to an enclosing
// scope lexically later than the deeper scope.
Load macros from external modules
2013-12-25 11:10:33 -07:00
struct MapChainFrame {
Rewrite SyntaxEnv I'd really like to be able to do something like struct MapChain<'next, K, V> { info: BlockInfo, map: HashMap<K, V>, next: Option<&'next mut MapChain<'next, K, V> } but I can't get the lifetimes to work out.
2013-12-30 17:45:39 -08:00
info: BlockInfo,
Moved `syntax::ext::base::SyntaxEnv` into `syntax::ext::base::ExtCtx`
2014-07-19 21:34:24 +02:00
map: HashMap<Name, Rc<SyntaxExtension>>,
Rewrite SyntaxEnv I'd really like to be able to do something like struct MapChain<'next, K, V> { info: BlockInfo, map: HashMap<K, V>, next: Option<&'next mut MapChain<'next, K, V> } but I can't get the lifetimes to work out.
2013-12-30 17:45:39 -08:00
}
Macros now leave scope Macro scope is now delimited by function, block, and module boundaries, except for modules that are marked with #[macro_escape], which allows macros to escape.
2013-02-26 10:15:29 -08:00
Load macros from external modules
2013-12-25 11:10:33 -07:00
impl SyntaxEnv {
Moved `syntax::ext::base::SyntaxEnv` into `syntax::ext::base::ExtCtx`
2014-07-19 21:34:24 +02:00
fn new() -> SyntaxEnv {
libsyntax: Mechanically change `~[T]` to `Vec<T>`
2014-02-28 13:09:09 -08:00
let mut map = SyntaxEnv { chain: Vec::new() };
Rewrite SyntaxEnv I'd really like to be able to do something like struct MapChain<'next, K, V> { info: BlockInfo, map: HashMap<K, V>, next: Option<&'next mut MapChain<'next, K, V> } but I can't get the lifetimes to work out.
2013-12-30 17:45:39 -08:00
map.push_frame();
map
Macros now leave scope Macro scope is now delimited by function, block, and module boundaries, except for modules that are marked with #[macro_escape], which allows macros to escape.
2013-02-26 10:15:29 -08:00
}
Rewrite SyntaxEnv I'd really like to be able to do something like struct MapChain<'next, K, V> { info: BlockInfo, map: HashMap<K, V>, next: Option<&'next mut MapChain<'next, K, V> } but I can't get the lifetimes to work out.
2013-12-30 17:45:39 -08:00
pub fn push_frame(&mut self) {
self.chain.push(MapChainFrame {
info: BlockInfo::new(),
map: HashMap::new(),
});
Macros now leave scope Macro scope is now delimited by function, block, and module boundaries, except for modules that are marked with #[macro_escape], which allows macros to escape.
2013-02-26 10:15:29 -08:00
}
Rewrite SyntaxEnv I'd really like to be able to do something like struct MapChain<'next, K, V> { info: BlockInfo, map: HashMap<K, V>, next: Option<&'next mut MapChain<'next, K, V> } but I can't get the lifetimes to work out.
2013-12-30 17:45:39 -08:00
pub fn pop_frame(&mut self) {
assert!(self.chain.len() > 1, "too many pops on MapChain!");
self.chain.pop();
Issue #5656: Make &self not mean "&'self self" Fixes #5656. Fixes #5541.
2013-04-10 13:11:27 -07:00
}
Load macros from external modules
2013-12-25 11:10:33 -07:00
fn find_escape_frame<'a>(&'a mut self) -> &'a mut MapChainFrame {
Fallout from renaming
2014-09-14 20:27:36 -07:00
for (i, frame) in self.chain.iter_mut().enumerate().rev() {
Rewrite SyntaxEnv I'd really like to be able to do something like struct MapChain<'next, K, V> { info: BlockInfo, map: HashMap<K, V>, next: Option<&'next mut MapChain<'next, K, V> } but I can't get the lifetimes to work out.
2013-12-30 17:45:39 -08:00
if !frame.info.macros_escape || i == 0 {
return frame
}
Macros now leave scope Macro scope is now delimited by function, block, and module boundaries, except for modules that are marked with #[macro_escape], which allows macros to escape.
2013-02-26 10:15:29 -08:00
}
Rewrite SyntaxEnv I'd really like to be able to do something like struct MapChain<'next, K, V> { info: BlockInfo, map: HashMap<K, V>, next: Option<&'next mut MapChain<'next, K, V> } but I can't get the lifetimes to work out.
2013-12-30 17:45:39 -08:00
unreachable!()
Macros now leave scope Macro scope is now delimited by function, block, and module boundaries, except for modules that are marked with #[macro_escape], which allows macros to escape.
2013-02-26 10:15:29 -08:00
}
Moved `syntax::ext::base::SyntaxEnv` into `syntax::ext::base::ExtCtx`
2014-07-19 21:34:24 +02:00
pub fn find(&self, k: &Name) -> Option<Rc<SyntaxExtension>> {
Update flip() to be rev(). Consensus leaned in favour of using rev instead of flip.
2014-01-23 20:41:57 +01:00
for frame in self.chain.iter().rev() {
Fallout from collection conventions
2014-11-06 12:25:16 -05:00
match frame.map.get(k) {
Moved `syntax::ext::base::SyntaxEnv` into `syntax::ext::base::ExtCtx`
2014-07-19 21:34:24 +02:00
Some(v) => return Some(v.clone()),
Rewrite SyntaxEnv I'd really like to be able to do something like struct MapChain<'next, K, V> { info: BlockInfo, map: HashMap<K, V>, next: Option<&'next mut MapChain<'next, K, V> } but I can't get the lifetimes to work out.
2013-12-30 17:45:39 -08:00
None => {}
Macros now leave scope Macro scope is now delimited by function, block, and module boundaries, except for modules that are marked with #[macro_escape], which allows macros to escape.
2013-02-26 10:15:29 -08:00
}
}
Rewrite SyntaxEnv I'd really like to be able to do something like struct MapChain<'next, K, V> { info: BlockInfo, map: HashMap<K, V>, next: Option<&'next mut MapChain<'next, K, V> } but I can't get the lifetimes to work out.
2013-12-30 17:45:39 -08:00
None
Macros now leave scope Macro scope is now delimited by function, block, and module boundaries, except for modules that are marked with #[macro_escape], which allows macros to escape.
2013-02-26 10:15:29 -08:00
}
Load macros from external modules
2013-12-25 11:10:33 -07:00
pub fn insert(&mut self, k: Name, v: SyntaxExtension) {
Moved `syntax::ext::base::SyntaxEnv` into `syntax::ext::base::ExtCtx`
2014-07-19 21:34:24 +02:00
self.find_escape_frame().map.insert(k, Rc::new(v));
Macros now leave scope Macro scope is now delimited by function, block, and module boundaries, except for modules that are marked with #[macro_escape], which allows macros to escape.
2013-02-26 10:15:29 -08:00
}
Load macros from external modules
2013-12-25 11:10:33 -07:00
pub fn info<'a>(&'a mut self) -> &'a mut BlockInfo {
libsyntax: Fix errors arising from the automated `~[T]` conversion
2014-02-28 12:54:01 -08:00
let last_chain_index = self.chain.len() - 1;
collections: Enable IndexMut for some collections This commit enables implementations of IndexMut for a number of collections, including Vec, RingBuf, SmallIntMap, TrieMap, TreeMap, and HashMap. At the same time this deprecates the `get_mut` methods on vectors in favor of using the indexing notation. cc #18424
2014-10-23 08:42:21 -07:00
&mut self.chain[last_chain_index].info
Macros now leave scope Macro scope is now delimited by function, block, and module boundaries, except for modules that are marked with #[macro_escape], which allows macros to escape.
2013-02-26 10:15:29 -08:00
}
}
Reference in New Issue Copy Permalink