2019-07-26 16:54:25 -05:00
|
|
|
// run-pass
|
2017-07-20 15:53:56 -05:00
|
|
|
// ignore-cross-compile
|
|
|
|
|
2017-08-14 17:26:55 -05:00
|
|
|
// The general idea of this test is to enumerate all "interesting" expressions and check that
|
2019-02-28 16:43:53 -06:00
|
|
|
// `parse(print(e)) == e` for all `e`. Here's what's interesting, for the purposes of this test:
|
2017-08-14 17:26:55 -05:00
|
|
|
//
|
2019-02-28 16:43:53 -06:00
|
|
|
// 1. The test focuses on expression nesting, because interactions between different expression
|
|
|
|
// types are harder to test manually than single expression types in isolation.
|
2017-08-14 17:26:55 -05:00
|
|
|
//
|
2019-02-28 16:43:53 -06:00
|
|
|
// 2. The test only considers expressions of at most two nontrivial nodes. So it will check `x +
|
|
|
|
// x` and `x + (x - x)` but not `(x * x) + (x - x)`. The assumption here is that the correct
|
|
|
|
// handling of an expression might depend on the expression's parent, but doesn't depend on its
|
|
|
|
// siblings or any more distant ancestors.
|
2017-08-14 17:26:55 -05:00
|
|
|
//
|
2019-02-28 16:43:53 -06:00
|
|
|
// 3. The test only checks certain expression kinds. The assumption is that similar expression
|
|
|
|
// types, such as `if` and `while` or `+` and `-`, will be handled identically in the printer
|
|
|
|
// and parser. So if all combinations of exprs involving `if` work correctly, then combinations
|
2017-08-14 17:26:55 -05:00
|
|
|
// using `while`, `if let`, and so on will likely work as well.
|
|
|
|
|
2017-07-20 15:53:56 -05:00
|
|
|
#![feature(rustc_private)]
|
|
|
|
|
2018-08-05 05:04:56 -05:00
|
|
|
extern crate rustc_data_structures;
|
2017-07-20 15:53:56 -05:00
|
|
|
extern crate syntax;
|
|
|
|
|
2018-08-05 05:04:56 -05:00
|
|
|
use rustc_data_structures::thin_vec::ThinVec;
|
2017-07-20 15:53:56 -05:00
|
|
|
use syntax::ast::*;
|
2018-08-18 05:14:03 -05:00
|
|
|
use syntax::source_map::{Spanned, DUMMY_SP, FileName};
|
|
|
|
use syntax::source_map::FilePathMapping;
|
Overhaul `syntax::fold::Folder`.
This commit changes `syntax::fold::Folder` from a functional style
(where most methods take a `T` and produce a new `T`) to a more
imperative style (where most methods take and modify a `&mut T`), and
renames it `syntax::mut_visit::MutVisitor`.
The first benefit is speed. The functional style does not require any
reallocations, due to the use of `P::map` and
`MoveMap::move_{,flat_}map`. However, every field in the AST must be
overwritten; even those fields that are unchanged are overwritten with
the same value. This causes a lot of unnecessary memory writes. The
imperative style reduces instruction counts by 1--3% across a wide range
of workloads, particularly incremental workloads.
The second benefit is conciseness; the imperative style is usually more
concise. E.g. compare the old functional style:
```
fn fold_abc(&mut self, abc: ABC) {
ABC {
a: fold_a(abc.a),
b: fold_b(abc.b),
c: abc.c,
}
}
```
with the imperative style:
```
fn visit_abc(&mut self, ABC { a, b, c: _ }: &mut ABC) {
visit_a(a);
visit_b(b);
}
```
(The reductions get larger in more complex examples.)
Overall, the patch removes over 200 lines of code -- even though the new
code has more comments -- and a lot of the remaining lines have fewer
characters.
Some notes:
- The old style used methods called `fold_*`. The new style mostly uses
methods called `visit_*`, but there are a few methods that map a `T`
to something other than a `T`, which are called `flat_map_*` (`T` maps
to multiple `T`s) or `filter_map_*` (`T` maps to 0 or 1 `T`s).
- `move_map.rs`/`MoveMap`/`move_map`/`move_flat_map` are renamed
`map_in_place.rs`/`MapInPlace`/`map_in_place`/`flat_map_in_place` to
reflect their slightly changed signatures.
- Although this commit renames the `fold` module as `mut_visit`, it
keeps it in the `fold.rs` file, so as not to confuse git. The next
commit will rename the file.
2019-02-04 22:20:55 -06:00
|
|
|
use syntax::mut_visit::{self, MutVisitor, visit_clobber};
|
2017-07-20 15:53:56 -05:00
|
|
|
use syntax::parse::{self, ParseSess};
|
|
|
|
use syntax::print::pprust;
|
|
|
|
use syntax::ptr::P;
|
|
|
|
|
|
|
|
|
2019-09-05 17:29:31 -05:00
|
|
|
fn parse_expr(ps: &ParseSess, src: &str) -> Option<P<Expr>> {
|
2018-10-30 09:11:24 -05:00
|
|
|
let src_as_string = src.to_string();
|
|
|
|
|
2019-09-05 17:29:31 -05:00
|
|
|
let mut p = parse::new_parser_from_source_str(
|
|
|
|
ps,
|
|
|
|
FileName::Custom(src_as_string.clone()),
|
|
|
|
src_as_string,
|
|
|
|
);
|
|
|
|
p.parse_expr().map_err(|mut e| e.cancel()).ok()
|
2017-07-20 15:53:56 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
// Helper functions for building exprs
|
|
|
|
fn expr(kind: ExprKind) -> P<Expr> {
|
|
|
|
P(Expr {
|
|
|
|
id: DUMMY_NODE_ID,
|
2019-09-26 17:17:53 -05:00
|
|
|
kind,
|
2017-07-20 15:53:56 -05:00
|
|
|
span: DUMMY_SP,
|
|
|
|
attrs: ThinVec::new(),
|
|
|
|
})
|
|
|
|
}
|
|
|
|
|
|
|
|
fn make_x() -> P<Expr> {
|
2018-03-18 19:54:56 -05:00
|
|
|
let seg = PathSegment::from_ident(Ident::from_str("x"));
|
2018-03-17 19:53:41 -05:00
|
|
|
let path = Path { segments: vec![seg], span: DUMMY_SP };
|
2017-07-20 15:53:56 -05:00
|
|
|
expr(ExprKind::Path(None, path))
|
|
|
|
}
|
|
|
|
|
2019-02-09 15:23:30 -06:00
|
|
|
/// Iterate over exprs of depth up to `depth`. The goal is to explore all "interesting"
|
|
|
|
/// combinations of expression nesting. For example, we explore combinations using `if`, but not
|
2017-07-20 15:53:56 -05:00
|
|
|
/// `while` or `match`, since those should print and parse in much the same way as `if`.
|
2019-05-28 13:47:46 -05:00
|
|
|
fn iter_exprs(depth: usize, f: &mut dyn FnMut(P<Expr>)) {
|
2017-07-20 15:53:56 -05:00
|
|
|
if depth == 0 {
|
|
|
|
f(make_x());
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
let mut g = |e| f(expr(e));
|
|
|
|
|
2019-06-17 18:28:51 -05:00
|
|
|
for kind in 0..=19 {
|
2017-07-20 15:53:56 -05:00
|
|
|
match kind {
|
|
|
|
0 => iter_exprs(depth - 1, &mut |e| g(ExprKind::Box(e))),
|
2018-02-18 11:39:40 -06:00
|
|
|
1 => iter_exprs(depth - 1, &mut |e| g(ExprKind::Call(e, vec![]))),
|
|
|
|
2 => {
|
2018-03-18 19:54:56 -05:00
|
|
|
let seg = PathSegment::from_ident(Ident::from_str("x"));
|
2017-07-20 15:53:56 -05:00
|
|
|
iter_exprs(depth - 1, &mut |e| g(ExprKind::MethodCall(
|
|
|
|
seg.clone(), vec![e, make_x()])));
|
|
|
|
iter_exprs(depth - 1, &mut |e| g(ExprKind::MethodCall(
|
|
|
|
seg.clone(), vec![make_x(), e])));
|
|
|
|
},
|
2019-06-17 18:28:51 -05:00
|
|
|
3..=8 => {
|
|
|
|
let op = Spanned {
|
|
|
|
span: DUMMY_SP,
|
|
|
|
node: match kind {
|
|
|
|
3 => BinOpKind::Add,
|
|
|
|
4 => BinOpKind::Mul,
|
|
|
|
5 => BinOpKind::Shl,
|
|
|
|
6 => BinOpKind::And,
|
|
|
|
7 => BinOpKind::Or,
|
|
|
|
8 => BinOpKind::Lt,
|
|
|
|
_ => unreachable!(),
|
|
|
|
}
|
|
|
|
};
|
2017-07-20 15:53:56 -05:00
|
|
|
iter_exprs(depth - 1, &mut |e| g(ExprKind::Binary(op, e, make_x())));
|
|
|
|
iter_exprs(depth - 1, &mut |e| g(ExprKind::Binary(op, make_x(), e)));
|
|
|
|
},
|
2019-06-17 18:28:51 -05:00
|
|
|
9 => {
|
2017-07-20 15:53:56 -05:00
|
|
|
iter_exprs(depth - 1, &mut |e| g(ExprKind::Unary(UnOp::Deref, e)));
|
|
|
|
},
|
2019-06-17 18:28:51 -05:00
|
|
|
10 => {
|
2017-07-20 15:53:56 -05:00
|
|
|
let block = P(Block {
|
|
|
|
stmts: Vec::new(),
|
|
|
|
id: DUMMY_NODE_ID,
|
|
|
|
rules: BlockCheckMode::Default,
|
|
|
|
span: DUMMY_SP,
|
|
|
|
});
|
|
|
|
iter_exprs(depth - 1, &mut |e| g(ExprKind::If(e, block.clone(), None)));
|
|
|
|
},
|
2019-06-17 18:28:51 -05:00
|
|
|
11 => {
|
2017-07-20 15:53:56 -05:00
|
|
|
let decl = P(FnDecl {
|
|
|
|
inputs: vec![],
|
|
|
|
output: FunctionRetTy::Default(DUMMY_SP),
|
|
|
|
});
|
|
|
|
iter_exprs(depth - 1, &mut |e| g(
|
2017-10-07 09:36:28 -05:00
|
|
|
ExprKind::Closure(CaptureBy::Value,
|
2018-06-19 21:12:41 -05:00
|
|
|
IsAsync::NotAsync,
|
2017-10-07 09:36:28 -05:00
|
|
|
Movability::Movable,
|
|
|
|
decl.clone(),
|
|
|
|
e,
|
|
|
|
DUMMY_SP)));
|
2017-07-20 15:53:56 -05:00
|
|
|
},
|
2019-06-17 18:28:51 -05:00
|
|
|
12 => {
|
2017-07-20 15:53:56 -05:00
|
|
|
iter_exprs(depth - 1, &mut |e| g(ExprKind::Assign(e, make_x())));
|
|
|
|
iter_exprs(depth - 1, &mut |e| g(ExprKind::Assign(make_x(), e)));
|
|
|
|
},
|
2019-06-17 18:28:51 -05:00
|
|
|
13 => {
|
2018-03-18 17:21:30 -05:00
|
|
|
iter_exprs(depth - 1, &mut |e| g(ExprKind::Field(e, Ident::from_str("f"))));
|
2017-07-20 15:53:56 -05:00
|
|
|
},
|
2019-06-17 18:28:51 -05:00
|
|
|
14 => {
|
2017-07-20 15:53:56 -05:00
|
|
|
iter_exprs(depth - 1, &mut |e| g(ExprKind::Range(
|
|
|
|
Some(e), Some(make_x()), RangeLimits::HalfOpen)));
|
|
|
|
iter_exprs(depth - 1, &mut |e| g(ExprKind::Range(
|
|
|
|
Some(make_x()), Some(e), RangeLimits::HalfOpen)));
|
|
|
|
},
|
2019-06-17 18:28:51 -05:00
|
|
|
15 => {
|
2017-07-20 15:53:56 -05:00
|
|
|
iter_exprs(depth - 1, &mut |e| g(ExprKind::AddrOf(Mutability::Immutable, e)));
|
|
|
|
},
|
2019-06-17 18:28:51 -05:00
|
|
|
16 => {
|
2017-07-20 15:53:56 -05:00
|
|
|
g(ExprKind::Ret(None));
|
|
|
|
iter_exprs(depth - 1, &mut |e| g(ExprKind::Ret(Some(e))));
|
|
|
|
},
|
2019-06-17 18:28:51 -05:00
|
|
|
17 => {
|
2018-03-18 19:54:56 -05:00
|
|
|
let path = Path::from_ident(Ident::from_str("S"));
|
2017-07-20 15:53:56 -05:00
|
|
|
g(ExprKind::Struct(path, vec![], Some(make_x())));
|
|
|
|
},
|
2019-06-17 18:28:51 -05:00
|
|
|
18 => {
|
2017-07-20 15:53:56 -05:00
|
|
|
iter_exprs(depth - 1, &mut |e| g(ExprKind::Try(e)));
|
|
|
|
},
|
2019-06-17 18:28:51 -05:00
|
|
|
19 => {
|
2019-09-02 23:58:09 -05:00
|
|
|
let pat = P(Pat {
|
2019-06-17 18:28:51 -05:00
|
|
|
id: DUMMY_NODE_ID,
|
2019-09-26 10:18:31 -05:00
|
|
|
kind: PatKind::Wild,
|
2019-06-17 18:28:51 -05:00
|
|
|
span: DUMMY_SP,
|
2019-09-02 23:58:09 -05:00
|
|
|
});
|
|
|
|
iter_exprs(depth - 1, &mut |e| g(ExprKind::Let(pat.clone(), e)))
|
2019-06-17 18:28:51 -05:00
|
|
|
},
|
2017-07-20 15:53:56 -05:00
|
|
|
_ => panic!("bad counter value in iter_exprs"),
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2019-02-28 16:43:53 -06:00
|
|
|
// Folders for manipulating the placement of `Paren` nodes. See below for why this is needed.
|
2017-07-20 15:53:56 -05:00
|
|
|
|
2019-02-28 16:43:53 -06:00
|
|
|
/// `MutVisitor` that removes all `ExprKind::Paren` nodes.
|
2017-07-20 15:53:56 -05:00
|
|
|
struct RemoveParens;
|
|
|
|
|
Overhaul `syntax::fold::Folder`.
This commit changes `syntax::fold::Folder` from a functional style
(where most methods take a `T` and produce a new `T`) to a more
imperative style (where most methods take and modify a `&mut T`), and
renames it `syntax::mut_visit::MutVisitor`.
The first benefit is speed. The functional style does not require any
reallocations, due to the use of `P::map` and
`MoveMap::move_{,flat_}map`. However, every field in the AST must be
overwritten; even those fields that are unchanged are overwritten with
the same value. This causes a lot of unnecessary memory writes. The
imperative style reduces instruction counts by 1--3% across a wide range
of workloads, particularly incremental workloads.
The second benefit is conciseness; the imperative style is usually more
concise. E.g. compare the old functional style:
```
fn fold_abc(&mut self, abc: ABC) {
ABC {
a: fold_a(abc.a),
b: fold_b(abc.b),
c: abc.c,
}
}
```
with the imperative style:
```
fn visit_abc(&mut self, ABC { a, b, c: _ }: &mut ABC) {
visit_a(a);
visit_b(b);
}
```
(The reductions get larger in more complex examples.)
Overall, the patch removes over 200 lines of code -- even though the new
code has more comments -- and a lot of the remaining lines have fewer
characters.
Some notes:
- The old style used methods called `fold_*`. The new style mostly uses
methods called `visit_*`, but there are a few methods that map a `T`
to something other than a `T`, which are called `flat_map_*` (`T` maps
to multiple `T`s) or `filter_map_*` (`T` maps to 0 or 1 `T`s).
- `move_map.rs`/`MoveMap`/`move_map`/`move_flat_map` are renamed
`map_in_place.rs`/`MapInPlace`/`map_in_place`/`flat_map_in_place` to
reflect their slightly changed signatures.
- Although this commit renames the `fold` module as `mut_visit`, it
keeps it in the `fold.rs` file, so as not to confuse git. The next
commit will rename the file.
2019-02-04 22:20:55 -06:00
|
|
|
impl MutVisitor for RemoveParens {
|
|
|
|
fn visit_expr(&mut self, e: &mut P<Expr>) {
|
2019-09-26 08:39:48 -05:00
|
|
|
match e.kind.clone() {
|
Overhaul `syntax::fold::Folder`.
This commit changes `syntax::fold::Folder` from a functional style
(where most methods take a `T` and produce a new `T`) to a more
imperative style (where most methods take and modify a `&mut T`), and
renames it `syntax::mut_visit::MutVisitor`.
The first benefit is speed. The functional style does not require any
reallocations, due to the use of `P::map` and
`MoveMap::move_{,flat_}map`. However, every field in the AST must be
overwritten; even those fields that are unchanged are overwritten with
the same value. This causes a lot of unnecessary memory writes. The
imperative style reduces instruction counts by 1--3% across a wide range
of workloads, particularly incremental workloads.
The second benefit is conciseness; the imperative style is usually more
concise. E.g. compare the old functional style:
```
fn fold_abc(&mut self, abc: ABC) {
ABC {
a: fold_a(abc.a),
b: fold_b(abc.b),
c: abc.c,
}
}
```
with the imperative style:
```
fn visit_abc(&mut self, ABC { a, b, c: _ }: &mut ABC) {
visit_a(a);
visit_b(b);
}
```
(The reductions get larger in more complex examples.)
Overall, the patch removes over 200 lines of code -- even though the new
code has more comments -- and a lot of the remaining lines have fewer
characters.
Some notes:
- The old style used methods called `fold_*`. The new style mostly uses
methods called `visit_*`, but there are a few methods that map a `T`
to something other than a `T`, which are called `flat_map_*` (`T` maps
to multiple `T`s) or `filter_map_*` (`T` maps to 0 or 1 `T`s).
- `move_map.rs`/`MoveMap`/`move_map`/`move_flat_map` are renamed
`map_in_place.rs`/`MapInPlace`/`map_in_place`/`flat_map_in_place` to
reflect their slightly changed signatures.
- Although this commit renames the `fold` module as `mut_visit`, it
keeps it in the `fold.rs` file, so as not to confuse git. The next
commit will rename the file.
2019-02-04 22:20:55 -06:00
|
|
|
ExprKind::Paren(inner) => *e = inner,
|
|
|
|
_ => {}
|
2017-07-20 15:53:56 -05:00
|
|
|
};
|
Overhaul `syntax::fold::Folder`.
This commit changes `syntax::fold::Folder` from a functional style
(where most methods take a `T` and produce a new `T`) to a more
imperative style (where most methods take and modify a `&mut T`), and
renames it `syntax::mut_visit::MutVisitor`.
The first benefit is speed. The functional style does not require any
reallocations, due to the use of `P::map` and
`MoveMap::move_{,flat_}map`. However, every field in the AST must be
overwritten; even those fields that are unchanged are overwritten with
the same value. This causes a lot of unnecessary memory writes. The
imperative style reduces instruction counts by 1--3% across a wide range
of workloads, particularly incremental workloads.
The second benefit is conciseness; the imperative style is usually more
concise. E.g. compare the old functional style:
```
fn fold_abc(&mut self, abc: ABC) {
ABC {
a: fold_a(abc.a),
b: fold_b(abc.b),
c: abc.c,
}
}
```
with the imperative style:
```
fn visit_abc(&mut self, ABC { a, b, c: _ }: &mut ABC) {
visit_a(a);
visit_b(b);
}
```
(The reductions get larger in more complex examples.)
Overall, the patch removes over 200 lines of code -- even though the new
code has more comments -- and a lot of the remaining lines have fewer
characters.
Some notes:
- The old style used methods called `fold_*`. The new style mostly uses
methods called `visit_*`, but there are a few methods that map a `T`
to something other than a `T`, which are called `flat_map_*` (`T` maps
to multiple `T`s) or `filter_map_*` (`T` maps to 0 or 1 `T`s).
- `move_map.rs`/`MoveMap`/`move_map`/`move_flat_map` are renamed
`map_in_place.rs`/`MapInPlace`/`map_in_place`/`flat_map_in_place` to
reflect their slightly changed signatures.
- Although this commit renames the `fold` module as `mut_visit`, it
keeps it in the `fold.rs` file, so as not to confuse git. The next
commit will rename the file.
2019-02-04 22:20:55 -06:00
|
|
|
mut_visit::noop_visit_expr(e, self);
|
2017-07-20 15:53:56 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2019-02-28 16:43:53 -06:00
|
|
|
/// `MutVisitor` that inserts `ExprKind::Paren` nodes around every `Expr`.
|
2017-07-20 15:53:56 -05:00
|
|
|
struct AddParens;
|
|
|
|
|
Overhaul `syntax::fold::Folder`.
This commit changes `syntax::fold::Folder` from a functional style
(where most methods take a `T` and produce a new `T`) to a more
imperative style (where most methods take and modify a `&mut T`), and
renames it `syntax::mut_visit::MutVisitor`.
The first benefit is speed. The functional style does not require any
reallocations, due to the use of `P::map` and
`MoveMap::move_{,flat_}map`. However, every field in the AST must be
overwritten; even those fields that are unchanged are overwritten with
the same value. This causes a lot of unnecessary memory writes. The
imperative style reduces instruction counts by 1--3% across a wide range
of workloads, particularly incremental workloads.
The second benefit is conciseness; the imperative style is usually more
concise. E.g. compare the old functional style:
```
fn fold_abc(&mut self, abc: ABC) {
ABC {
a: fold_a(abc.a),
b: fold_b(abc.b),
c: abc.c,
}
}
```
with the imperative style:
```
fn visit_abc(&mut self, ABC { a, b, c: _ }: &mut ABC) {
visit_a(a);
visit_b(b);
}
```
(The reductions get larger in more complex examples.)
Overall, the patch removes over 200 lines of code -- even though the new
code has more comments -- and a lot of the remaining lines have fewer
characters.
Some notes:
- The old style used methods called `fold_*`. The new style mostly uses
methods called `visit_*`, but there are a few methods that map a `T`
to something other than a `T`, which are called `flat_map_*` (`T` maps
to multiple `T`s) or `filter_map_*` (`T` maps to 0 or 1 `T`s).
- `move_map.rs`/`MoveMap`/`move_map`/`move_flat_map` are renamed
`map_in_place.rs`/`MapInPlace`/`map_in_place`/`flat_map_in_place` to
reflect their slightly changed signatures.
- Although this commit renames the `fold` module as `mut_visit`, it
keeps it in the `fold.rs` file, so as not to confuse git. The next
commit will rename the file.
2019-02-04 22:20:55 -06:00
|
|
|
impl MutVisitor for AddParens {
|
|
|
|
fn visit_expr(&mut self, e: &mut P<Expr>) {
|
|
|
|
mut_visit::noop_visit_expr(e, self);
|
|
|
|
visit_clobber(e, |e| {
|
|
|
|
P(Expr {
|
|
|
|
id: DUMMY_NODE_ID,
|
2019-09-26 08:39:48 -05:00
|
|
|
kind: ExprKind::Paren(e),
|
Overhaul `syntax::fold::Folder`.
This commit changes `syntax::fold::Folder` from a functional style
(where most methods take a `T` and produce a new `T`) to a more
imperative style (where most methods take and modify a `&mut T`), and
renames it `syntax::mut_visit::MutVisitor`.
The first benefit is speed. The functional style does not require any
reallocations, due to the use of `P::map` and
`MoveMap::move_{,flat_}map`. However, every field in the AST must be
overwritten; even those fields that are unchanged are overwritten with
the same value. This causes a lot of unnecessary memory writes. The
imperative style reduces instruction counts by 1--3% across a wide range
of workloads, particularly incremental workloads.
The second benefit is conciseness; the imperative style is usually more
concise. E.g. compare the old functional style:
```
fn fold_abc(&mut self, abc: ABC) {
ABC {
a: fold_a(abc.a),
b: fold_b(abc.b),
c: abc.c,
}
}
```
with the imperative style:
```
fn visit_abc(&mut self, ABC { a, b, c: _ }: &mut ABC) {
visit_a(a);
visit_b(b);
}
```
(The reductions get larger in more complex examples.)
Overall, the patch removes over 200 lines of code -- even though the new
code has more comments -- and a lot of the remaining lines have fewer
characters.
Some notes:
- The old style used methods called `fold_*`. The new style mostly uses
methods called `visit_*`, but there are a few methods that map a `T`
to something other than a `T`, which are called `flat_map_*` (`T` maps
to multiple `T`s) or `filter_map_*` (`T` maps to 0 or 1 `T`s).
- `move_map.rs`/`MoveMap`/`move_map`/`move_flat_map` are renamed
`map_in_place.rs`/`MapInPlace`/`map_in_place`/`flat_map_in_place` to
reflect their slightly changed signatures.
- Although this commit renames the `fold` module as `mut_visit`, it
keeps it in the `fold.rs` file, so as not to confuse git. The next
commit will rename the file.
2019-02-04 22:20:55 -06:00
|
|
|
span: DUMMY_SP,
|
|
|
|
attrs: ThinVec::new(),
|
|
|
|
})
|
|
|
|
});
|
2017-07-20 15:53:56 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
fn main() {
|
2019-04-05 17:15:49 -05:00
|
|
|
syntax::with_default_globals(|| run());
|
2018-03-06 19:44:10 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
fn run() {
|
2017-07-20 15:53:56 -05:00
|
|
|
let ps = ParseSess::new(FilePathMapping::empty());
|
|
|
|
|
Overhaul `syntax::fold::Folder`.
This commit changes `syntax::fold::Folder` from a functional style
(where most methods take a `T` and produce a new `T`) to a more
imperative style (where most methods take and modify a `&mut T`), and
renames it `syntax::mut_visit::MutVisitor`.
The first benefit is speed. The functional style does not require any
reallocations, due to the use of `P::map` and
`MoveMap::move_{,flat_}map`. However, every field in the AST must be
overwritten; even those fields that are unchanged are overwritten with
the same value. This causes a lot of unnecessary memory writes. The
imperative style reduces instruction counts by 1--3% across a wide range
of workloads, particularly incremental workloads.
The second benefit is conciseness; the imperative style is usually more
concise. E.g. compare the old functional style:
```
fn fold_abc(&mut self, abc: ABC) {
ABC {
a: fold_a(abc.a),
b: fold_b(abc.b),
c: abc.c,
}
}
```
with the imperative style:
```
fn visit_abc(&mut self, ABC { a, b, c: _ }: &mut ABC) {
visit_a(a);
visit_b(b);
}
```
(The reductions get larger in more complex examples.)
Overall, the patch removes over 200 lines of code -- even though the new
code has more comments -- and a lot of the remaining lines have fewer
characters.
Some notes:
- The old style used methods called `fold_*`. The new style mostly uses
methods called `visit_*`, but there are a few methods that map a `T`
to something other than a `T`, which are called `flat_map_*` (`T` maps
to multiple `T`s) or `filter_map_*` (`T` maps to 0 or 1 `T`s).
- `move_map.rs`/`MoveMap`/`move_map`/`move_flat_map` are renamed
`map_in_place.rs`/`MapInPlace`/`map_in_place`/`flat_map_in_place` to
reflect their slightly changed signatures.
- Although this commit renames the `fold` module as `mut_visit`, it
keeps it in the `fold.rs` file, so as not to confuse git. The next
commit will rename the file.
2019-02-04 22:20:55 -06:00
|
|
|
iter_exprs(2, &mut |mut e| {
|
2017-07-20 15:53:56 -05:00
|
|
|
// If the pretty printer is correct, then `parse(print(e))` should be identical to `e`,
|
|
|
|
// modulo placement of `Paren` nodes.
|
|
|
|
let printed = pprust::expr_to_string(&e);
|
|
|
|
println!("printed: {}", printed);
|
|
|
|
|
2019-09-05 17:29:31 -05:00
|
|
|
// Ignore expressions with chained comparisons that fail to parse
|
|
|
|
if let Some(mut parsed) = parse_expr(&ps, &printed) {
|
|
|
|
// We want to know if `parsed` is structurally identical to `e`, ignoring trivial
|
|
|
|
// differences like placement of `Paren`s or the exact ranges of node spans.
|
|
|
|
// Unfortunately, there is no easy way to make this comparison. Instead, we add `Paren`s
|
|
|
|
// everywhere we can, then pretty-print. This should give an unambiguous representation
|
|
|
|
// of each `Expr`, and it bypasses nearly all of the parenthesization logic, so we
|
|
|
|
// aren't relying on the correctness of the very thing we're testing.
|
|
|
|
RemoveParens.visit_expr(&mut e);
|
|
|
|
AddParens.visit_expr(&mut e);
|
|
|
|
let text1 = pprust::expr_to_string(&e);
|
|
|
|
RemoveParens.visit_expr(&mut parsed);
|
|
|
|
AddParens.visit_expr(&mut parsed);
|
|
|
|
let text2 = pprust::expr_to_string(&parsed);
|
|
|
|
assert!(text1 == text2,
|
|
|
|
"exprs are not equal:\n e = {:?}\n parsed = {:?}",
|
|
|
|
text1, text2);
|
|
|
|
}
|
2017-07-20 15:53:56 -05:00
|
|
|
});
|
|
|
|
}
|