rust/src/test/ui/macros/macro-interpolation.rs

// run-pass

macro_rules! overly_complicated {
    ($fnname:ident, $arg:ident, $ty:ty, $body:block, $val:expr, $pat:pat, $res:path) =>
    ({
        fn $fnname($arg: $ty) -> Option<$ty> $body
        match $fnname($val) {
          Some($pat) => {
            $res
          }
          _ => { panic!(); }
        }
    })

}

pub fn main() {
    assert!(overly_complicated!(f, x, Option<usize>, { return Some(x); },
                               Some(8), Some(y), y) == 8)

}
Add `// run-pass` annotations to all the tests under `ui/run-pass/`. (I may have accidentally added it to some auxilliary crates as well; my emacs-macro-based methodology was pretty crude.) 2018-08-30 14:18:55 +02:00			`// run-pass`
rustdoc: Replace no-pretty-expanded with pretty-expanded Now that features must be declared expanded source often does not compile. This adds 'pretty-expanded' to a bunch of test cases that still work. 2015-03-22 13:13:15 -07:00
Modernize macro_rules! invocations macro_rules! is like an item that defines a macro. Other items don't have a trailing semicolon, or use a paren-delimited body. If there's an argument for matching the invocation syntax, e.g. parentheses for an expr macro, then I think that applies more strongly to the inner delimiters on the LHS, wrapping the individual argument patterns. 2015-01-02 14:44:21 -08:00			`macro_rules! overly_complicated {`
Eliminate some extraneous curly brackets inside invocations of `macro_rules!`. 2012-08-22 18:06:54 -07:00			`($fnname:ident, $arg:ident, $ty:ty, $body:block, $val:expr, $pat:pat, $res:path) =>`
Update tests to respect the way that macros work now. 2012-11-21 15:53:49 -05:00			`({`
Camel case the option type 2012-08-20 12:23:37 -07:00			`fn $fnname($arg: $ty) -> Option<$ty> $body`
Convert alt to match. Stop parsing alt 2012-08-06 12:34:08 -07:00			`match $fnname($val) {`
Camel case the option type 2012-08-20 12:23:37 -07:00			`Some($pat) => {`
Allow interpolations of all the nt_*s. 2012-08-01 14:34:35 -07:00			`$res`
			`}`
Rename fail! to panic! https://github.com/rust-lang/rfcs/pull/221 The current terminology of "task failure" often causes problems when writing or speaking about code. You often want to talk about the possibility of an operation that returns a Result "failing", but cannot because of the ambiguity with task failure. Instead, you have to speak of "the failing case" or "when the operation does not succeed" or other circumlocutions. Likewise, we use a "Failure" header in rustdoc to describe when operations may fail the task, but it would often be helpful to separate out a section describing the "Err-producing" case. We have been steadily moving away from task failure and toward Result as an error-handling mechanism, so we should optimize our terminology accordingly: Result-producing functions should be easy to describe. To update your code, rename any call to `fail!` to `panic!` instead. Assuming you have not created your own macro named `panic!`, this will work on UNIX based systems: grep -lZR 'fail!' . \| xargs -0 -l sed -i -e 's/fail!/panic!/g' You can of course also do this by hand. [breaking-change] 2014-10-09 15:17:22 -04:00			`_ => { panic!(); }`
Allow interpolations of all the nt_*s. 2012-08-01 14:34:35 -07:00			`}`
Update tests to respect the way that macros work now. 2012-11-21 15:53:49 -05:00			`})`
Allow interpolations of all the nt_*s. 2012-08-01 14:34:35 -07:00
Modernize macro_rules! invocations macro_rules! is like an item that defines a macro. Other items don't have a trailing semicolon, or use a paren-delimited body. If there's an argument for matching the invocation syntax, e.g. parentheses for an expr macro, then I think that applies more strongly to the inner delimiters on the LHS, wrapping the individual argument patterns. 2015-01-02 14:44:21 -08:00			`}`
librustc: Always parse `macro!()`/`macro![]` as expressions if not followed by a semicolon. This allows code like `vec![1i, 2, 3].len();` to work. This breaks code that uses macros as statements without putting semicolons after them, such as: fn main() { ... assert!(a == b) assert!(c == d) println(...); } It also breaks code that uses macros as items without semicolons: local_data_key!(foo) fn main() { println("hello world") } Add semicolons to fix this code. Those two examples can be fixed as follows: fn main() { ... assert!(a == b); assert!(c == d); println(...); } local_data_key!(foo); fn main() { println("hello world") } RFC #378. Closes #18635. [breaking-change] 2014-11-14 09:18:10 -08:00
check-fast fallout from removing export, r=burningtree 2013-02-01 19:43:17 -08:00			`pub fn main() {`
Mass rename uint/int to usize/isize Now that support has been removed, all lingering use cases are renamed. 2015-03-25 17:06:52 -07:00			`assert!(overly_complicated!(f, x, Option<usize>, { return Some(x); },`
Remove integer suffixes where the types in compiled code are identical. 2015-03-03 10:42:26 +02:00			`Some(8), Some(y), y) == 8)`
Allow interpolations of all the nt_*s. 2012-08-01 14:34:35 -07:00
Replace most invocations of fail keyword with die! macro 2013-01-31 17:51:01 -08:00			`}`