| Age | Commit message (Collapse) | Author | Lines | |
|---|---|---|---|---|
| 2017-01-12 | resolve: Do not use "resolve"/"resolution" in error messages | Vadim Petrochenkov | -1/+1 | |
| 2016-12-26 | More systematic error reporting in path resolution | Vadim Petrochenkov | -1/+1 | |
| 2015-01-05 | Un-gate macro_rules | Keegan McAllister | -2/+0 | |
| 2015-01-05 | Modernize macro_rules! invocations | Keegan McAllister | -1/+1 | |
| 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. | ||||
| 2014-12-18 | librustc: Always parse `macro!()`/`macro![]` as expressions if not | Patrick Walton | -0/+18 | |
| 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] | ||||
