rust/src/libsyntax/ext/expand.rs, branch 1.6.0https://github.com/rust-lang/rust
http://git.dreamy.place/mirrors/rust/atom?h=1.6.02015-12-04T08:46:29+00:00Auto merge of #29850 - Kimundi:attributes_that_make_a_statement, r=pnkfelix2015-12-04T08:46:29+00:00borsbors@rust-lang.org2015-12-04T08:46:29+00:00urn:sha1:77ed39cfe37a17737e0b2256b1a1689e01c32b26
See https://github.com/rust-lang/rfcs/pull/16 and https://github.com/rust-lang/rust/issues/15701
- Added syntax support for attributes on expressions and all syntax nodes in statement position.
- Extended `#[cfg]` folder to allow removal of statements, and
of expressions in optional positions like expression lists and trailing
block expressions.
- Extended lint checker to recognize lint levels on expressions and
locals.
- As per RFC, attributes are not yet accepted on `if` expressions.
Examples:
```rust
let x = y;
{
...
}
assert_eq!((1, #[cfg(unset)] 2, 3), (1, 3));
let FOO = 0;
```
Implementation wise, there are a few rough corners and open questions:
- The parser work ended up a bit ugly.
- The pretty printer change was based mostly on guessing.
- Similar to the `if` case, there are some places in the grammar where a new `Expr` node starts,
but where it seemed weird to accept attributes and hence the parser doesn't. This includes:
- const expressions in patterns
- in the middle of an postfix operator chain (that is, after `.`, before indexing, before calls)
- on range expressions, since `#[attr] x .. y` parses as `(#[attr] x) .. y`, which is inconsistent with
`#[attr] .. y` which would parse as `#[attr] (.. y)`
- Attributes are added as additional `Option<Box<Vec<Attribute>>>` fields in expressions and locals.
- Memory impact has not been measured yet.
- A cfg-away trailing expression in a block does not currently promote the previous `StmtExpr` in a block to a new trailing expr. That is to say, this won't work:
```rust
let x = {
#[cfg(foo)]
Foo { data: x }
#[cfg(not(foo))]
Foo { data: y }
};
```
- One-element tuples can have their inner expression removed to become Unit, but just Parenthesis can't. Eg, `(#[cfg(unset)] x,) == ()` but `(#[cfg(unset)] x) == error`. This seemed reasonable to me since tuples and unit are type constructors, but could probably be argued either way.
- Attributes on macro nodes are currently unconditionally dropped during macro expansion, which seemed fine since macro disappear at that point?
- Attributes on `ast::ExprParens` will be prepend-ed to the inner expression in the hir folder.
- The work on pretty printer tests for this did trigger, but not fix errors regarding macros:
- expression `foo![]` prints as `foo!()`
- expression `foo!{}` prints as `foo!()`
- statement `foo![];` prints as `foo!();`
- statement `foo!{};` prints as `foo!();`
- statement `foo!{}` triggers a `None` unwrap ICE.
Improved comments around dropped attributes in the macro expander2015-11-30T21:26:03+00:00Marvin Löbelloebel.marvin@gmail.com2015-11-30T21:26:03+00:00urn:sha1:3f33cbcbff47182fef3437040c301c8ea30a5afcAdded stmt_expr_attribute feature gate2015-11-26T20:47:44+00:00Marvin Löbelloebel.marvin@gmail.com2015-11-24T13:56:20+00:00urn:sha1:296c3613ca7ed1117788f4e56259d2e426e992d7Some TLC for the MoveMap trait2015-11-26T20:46:12+00:00Marvin Löbelloebel.marvin@gmail.com2015-11-15T20:19:53+00:00urn:sha1:c56b47ab8cd2906e30960f05d51855f9f7f5255bFixed macro expander not folding attributes (though I'm not sure if that is actually neccessary)2015-11-26T20:46:12+00:00Marvin Löbelloebel.marvin@gmail.com2015-11-15T17:20:09+00:00urn:sha1:0608b1d4146fc9fb76860bf71ff2363164f17326Add syntax support for attributes on expressions and all syntax2015-11-26T20:46:12+00:00Marvin Löbelloebel.marvin@gmail.com2015-11-03T16:39:51+00:00urn:sha1:2a8f358de7ee71934b8129dff5d908730454d7b1
nodes in statement position.
Extended #[cfg] folder to allow removal of statements, and
of expressions in optional positions like expression lists and trailing
block expressions.
Extended lint checker to recognize lint levels on expressions and
locals.
Add suggestion of similar macro names to `macro undefined` error message2015-11-25T23:21:38+00:00Florian Hartwigflorian.j.hartwig@gmail.com2015-11-25T23:21:38+00:00urn:sha1:a5e5c6775629b912fd058e2a595f70e5457b3d46Look up macro names as well when suggesting replacements for function resolve errors2015-11-22T01:18:46+00:00Manish Goregaokarmanishsmail@gmail.com2015-11-21T09:37:50+00:00urn:sha1:99925fb562086ff789df95220104f9d8d5fc8b3c
fixes #5780
rename `ast::ImplItem_::*ImplItem` to `ast::ImplItemKind::*`2015-11-16T09:35:30+00:00Oliver Schneidergit-spam-no-reply9815368754983@oli-obk.de2015-11-13T13:15:04+00:00urn:sha1:d09220de13a72b283d824285a2883da9e014f3f7Use deref coercions2015-11-10T11:16:28+00:00Seo Sanghyeonsanxiyn@gmail.com2015-11-10T11:16:28+00:00urn:sha1:791003ad3c014c1ca12a29d35b4f8530aa4b7b76