Commit Graph

7 Commits

Author SHA1 Message Date
Aaron Turon
2234b557bb Adjust tests to new error message 2016-03-11 10:59:40 -08:00
Jonas Schievink
31fa44b18e Don't print the macro definition site in backtraces
This halves the backtrace length. The definition site wasn't very useful
anyways, since it may be invalid (for compiler expansions) or located in
another crate. Since the macro name is still printed, grepping for it is
still an easy way of finding the definition.
2015-09-10 22:25:28 +02:00
Eduard Burtescu
06f362aeb3 rustc_resolve: don't handle impl items as if they were modules. 2015-02-24 14:16:01 +02:00
Keegan McAllister
c2e26972e3 Un-gate macro_rules 2015-01-05 18:21:14 -08:00
Keegan McAllister
416137eb31 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-05 18:21:14 -08:00
Patrick Walton
ddb2466f6a 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-12-18 12:09:07 -05:00
Keegan McAllister
5b42f79ff0 Pop the expansion context after expanding a method macro
We were leaving these on the stack, causing spurious backtraces.

I've confirmed that this test fails without the fix.
2014-09-17 11:18:53 -07:00