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)]
|
|
|
|
|
2020-12-10 06:20:07 -06:00
|
|
|
extern crate rustc_ast;
|
2020-01-18 12:21:05 -06:00
|
|
|
extern crate rustc_ast_pretty;
|
2018-08-05 05:04:56 -05:00
|
|
|
extern crate rustc_data_structures;
|
2019-10-15 15:48:13 -05:00
|
|
|
extern crate rustc_parse;
|
2020-01-18 12:21:05 -06:00
|
|
|
extern crate rustc_session;
|
2020-01-01 17:01:07 -06:00
|
|
|
extern crate rustc_span;
|
2022-09-08 02:22:52 -05:00
|
|
|
extern crate thin_vec;
|
2017-07-20 15:53:56 -05:00
|
|
|
|
2022-12-12 13:37:28 -06:00
|
|
|
// Necessary to pull in object code as the rest of the rustc crates are shipped only as rmeta
|
|
|
|
// files.
|
|
|
|
#[allow(unused_extern_crates)]
|
|
|
|
extern crate rustc_driver;
|
|
|
|
|
2023-11-09 20:11:24 -06:00
|
|
|
use rustc_ast::mut_visit::{visit_clobber, MutVisitor};
|
2020-12-10 06:20:07 -06:00
|
|
|
use rustc_ast::ptr::P;
|
|
|
|
use rustc_ast::*;
|
2020-01-18 12:21:05 -06:00
|
|
|
use rustc_ast_pretty::pprust;
|
2019-10-15 15:48:13 -05:00
|
|
|
use rustc_parse::new_parser_from_source_str;
|
2020-01-18 12:21:05 -06:00
|
|
|
use rustc_session::parse::ParseSess;
|
2023-11-01 22:10:12 -05:00
|
|
|
use rustc_span::source_map::{FilePathMapping, Spanned};
|
2020-04-25 14:13:56 -05:00
|
|
|
use rustc_span::symbol::Ident;
|
2023-11-01 22:10:12 -05:00
|
|
|
use rustc_span::{FileName, DUMMY_SP};
|
2023-02-20 17:24:51 -06:00
|
|
|
use thin_vec::{thin_vec, ThinVec};
|
2017-07-20 15:53:56 -05:00
|
|
|
|
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();
|
|
|
|
|
2020-12-10 06:20:07 -06:00
|
|
|
let mut p =
|
|
|
|
new_parser_from_source_str(ps, FileName::Custom(src_as_string.clone()), src_as_string);
|
2022-01-25 21:39:14 -06:00
|
|
|
p.parse_expr().map_err(|e| e.cancel()).ok()
|
2017-07-20 15:53:56 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
// Helper functions for building exprs
|
|
|
|
fn expr(kind: ExprKind) -> P<Expr> {
|
2022-08-16 21:34:33 -05:00
|
|
|
P(Expr { id: DUMMY_NODE_ID, kind, span: DUMMY_SP, attrs: AttrVec::new(), tokens: None })
|
2017-07-20 15:53:56 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
fn make_x() -> P<Expr> {
|
2018-03-18 19:54:56 -05:00
|
|
|
let seg = PathSegment::from_ident(Ident::from_str("x"));
|
2022-09-08 02:22:52 -05:00
|
|
|
let path = Path { segments: thin_vec![seg], span: DUMMY_SP, tokens: None };
|
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));
|
|
|
|
|
2023-02-27 07:07:44 -06:00
|
|
|
for kind in 0..=18 {
|
2017-07-20 15:53:56 -05:00
|
|
|
match kind {
|
2023-02-27 07:07:44 -06:00
|
|
|
0 => iter_exprs(depth - 1, &mut |e| g(ExprKind::Call(e, thin_vec![]))),
|
|
|
|
1 => {
|
2018-03-18 19:54:56 -05:00
|
|
|
let seg = PathSegment::from_ident(Ident::from_str("x"));
|
2020-12-10 06:20:07 -06:00
|
|
|
iter_exprs(depth - 1, &mut |e| {
|
2022-09-07 19:52:51 -05:00
|
|
|
g(ExprKind::MethodCall(Box::new(MethodCall {
|
2023-09-08 11:14:47 -05:00
|
|
|
seg: seg.clone(),
|
|
|
|
receiver: e,
|
|
|
|
args: thin_vec![make_x()],
|
|
|
|
span: DUMMY_SP,
|
|
|
|
})))
|
|
|
|
});
|
2020-12-10 06:20:07 -06:00
|
|
|
iter_exprs(depth - 1, &mut |e| {
|
2022-09-07 19:52:51 -05:00
|
|
|
g(ExprKind::MethodCall(Box::new(MethodCall {
|
2023-09-08 11:14:47 -05:00
|
|
|
seg: seg.clone(),
|
|
|
|
receiver: make_x(),
|
|
|
|
args: thin_vec![e],
|
|
|
|
span: DUMMY_SP,
|
|
|
|
})))
|
|
|
|
});
|
2020-12-10 06:20:07 -06:00
|
|
|
}
|
2023-02-27 07:07:44 -06:00
|
|
|
2..=7 => {
|
2019-06-17 18:28:51 -05:00
|
|
|
let op = Spanned {
|
|
|
|
span: DUMMY_SP,
|
|
|
|
node: match kind {
|
2023-02-27 07:07:44 -06:00
|
|
|
2 => BinOpKind::Add,
|
|
|
|
3 => BinOpKind::Mul,
|
|
|
|
4 => BinOpKind::Shl,
|
|
|
|
5 => BinOpKind::And,
|
|
|
|
6 => BinOpKind::Or,
|
|
|
|
7 => BinOpKind::Lt,
|
2019-06-17 18:28:51 -05:00
|
|
|
_ => unreachable!(),
|
2020-12-10 06:20:07 -06:00
|
|
|
},
|
2019-06-17 18:28:51 -05:00
|
|
|
};
|
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)));
|
2020-12-10 06:20:07 -06:00
|
|
|
}
|
2023-02-27 07:07:44 -06:00
|
|
|
8 => {
|
2017-07-20 15:53:56 -05:00
|
|
|
iter_exprs(depth - 1, &mut |e| g(ExprKind::Unary(UnOp::Deref, e)));
|
2020-12-10 06:20:07 -06:00
|
|
|
}
|
2023-02-27 07:07:44 -06:00
|
|
|
9 => {
|
2017-07-20 15:53:56 -05:00
|
|
|
let block = P(Block {
|
2023-02-20 17:24:51 -06:00
|
|
|
stmts: ThinVec::new(),
|
2017-07-20 15:53:56 -05:00
|
|
|
id: DUMMY_NODE_ID,
|
|
|
|
rules: BlockCheckMode::Default,
|
|
|
|
span: DUMMY_SP,
|
2020-08-21 21:11:41 -05:00
|
|
|
tokens: None,
|
2021-09-02 13:34:03 -05:00
|
|
|
could_be_bare_literal: false,
|
2017-07-20 15:53:56 -05:00
|
|
|
});
|
|
|
|
iter_exprs(depth - 1, &mut |e| g(ExprKind::If(e, block.clone(), None)));
|
2020-12-10 06:20:07 -06:00
|
|
|
}
|
2023-02-27 07:07:44 -06:00
|
|
|
10 => {
|
2022-11-22 18:55:16 -06:00
|
|
|
let decl = P(FnDecl { inputs: thin_vec![], output: FnRetTy::Default(DUMMY_SP) });
|
2020-12-10 06:20:07 -06:00
|
|
|
iter_exprs(depth - 1, &mut |e| {
|
2022-09-07 19:52:51 -05:00
|
|
|
g(ExprKind::Closure(Box::new(Closure {
|
|
|
|
binder: ClosureBinder::NotPresent,
|
2023-11-04 15:04:54 -05:00
|
|
|
capture_clause: CaptureBy::Value { move_kw: DUMMY_SP },
|
2022-12-26 04:48:54 -06:00
|
|
|
constness: Const::No,
|
2023-12-05 15:39:36 -06:00
|
|
|
coroutine_kind: None,
|
2022-09-07 19:52:51 -05:00
|
|
|
movability: Movability::Movable,
|
|
|
|
fn_decl: decl.clone(),
|
|
|
|
body: e,
|
|
|
|
fn_decl_span: DUMMY_SP,
|
2022-11-09 09:09:28 -06:00
|
|
|
fn_arg_span: DUMMY_SP,
|
2022-09-07 19:52:51 -05:00
|
|
|
})))
|
2017-07-20 15:53:56 -05:00
|
|
|
});
|
2020-12-10 06:20:07 -06:00
|
|
|
}
|
2023-02-27 07:07:44 -06:00
|
|
|
11 => {
|
2019-12-22 15:08:53 -06:00
|
|
|
iter_exprs(depth - 1, &mut |e| g(ExprKind::Assign(e, make_x(), DUMMY_SP)));
|
|
|
|
iter_exprs(depth - 1, &mut |e| g(ExprKind::Assign(make_x(), e, DUMMY_SP)));
|
2020-12-10 06:20:07 -06:00
|
|
|
}
|
2023-02-27 07:07:44 -06:00
|
|
|
12 => {
|
2018-03-18 17:21:30 -05:00
|
|
|
iter_exprs(depth - 1, &mut |e| g(ExprKind::Field(e, Ident::from_str("f"))));
|
2020-12-10 06:20:07 -06:00
|
|
|
}
|
2023-02-27 07:07:44 -06:00
|
|
|
13 => {
|
2020-12-10 06:20:07 -06: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))
|
|
|
|
});
|
|
|
|
}
|
2023-02-27 07:07:44 -06:00
|
|
|
14 => {
|
2020-12-10 06:20:07 -06:00
|
|
|
iter_exprs(depth - 1, &mut |e| {
|
|
|
|
g(ExprKind::AddrOf(BorrowKind::Ref, Mutability::Not, e))
|
|
|
|
});
|
|
|
|
}
|
2023-02-27 07:07:44 -06:00
|
|
|
15 => {
|
2017-07-20 15:53:56 -05:00
|
|
|
g(ExprKind::Ret(None));
|
|
|
|
iter_exprs(depth - 1, &mut |e| g(ExprKind::Ret(Some(e))));
|
2020-12-10 06:20:07 -06:00
|
|
|
}
|
2023-02-27 07:07:44 -06:00
|
|
|
16 => {
|
2018-03-18 19:54:56 -05:00
|
|
|
let path = Path::from_ident(Ident::from_str("S"));
|
2021-03-15 19:15:53 -05:00
|
|
|
g(ExprKind::Struct(P(StructExpr {
|
2020-12-10 06:20:07 -06:00
|
|
|
qself: None,
|
|
|
|
path,
|
2023-02-20 17:24:51 -06:00
|
|
|
fields: thin_vec![],
|
2020-12-10 06:20:07 -06:00
|
|
|
rest: StructRest::Base(make_x()),
|
2021-03-15 19:15:53 -05:00
|
|
|
})));
|
2020-12-10 06:20:07 -06:00
|
|
|
}
|
2023-02-27 07:07:44 -06:00
|
|
|
17 => {
|
2017-07-20 15:53:56 -05:00
|
|
|
iter_exprs(depth - 1, &mut |e| g(ExprKind::Try(e)));
|
2020-12-10 06:20:07 -06:00
|
|
|
}
|
2023-02-27 07:07:44 -06:00
|
|
|
18 => {
|
2020-12-10 06:20:07 -06:00
|
|
|
let pat =
|
|
|
|
P(Pat { id: DUMMY_NODE_ID, kind: PatKind::Wild, span: DUMMY_SP, tokens: None });
|
2023-09-08 11:14:47 -05:00
|
|
|
iter_exprs(depth - 1, &mut |e| g(ExprKind::Let(pat.clone(), e, DUMMY_SP, None)))
|
2020-12-10 06:20:07 -06: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,
|
2022-08-16 21:34:33 -05:00
|
|
|
attrs: AttrVec::new(),
|
2020-12-10 06:20:07 -06:00
|
|
|
tokens: None,
|
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
|
|
|
})
|
|
|
|
});
|
2017-07-20 15:53:56 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
fn main() {
|
2021-05-05 14:31:25 -05:00
|
|
|
rustc_span::create_default_session_globals_then(|| run());
|
2018-03-06 19:44:10 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
fn run() {
|
2022-10-17 08:11:26 -05:00
|
|
|
let ps = ParseSess::new(vec![rustc_parse::DEFAULT_LOCALE_RESOURCE], FilePathMapping::empty());
|
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
|
|
|
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);
|
2020-12-10 06:20:07 -06:00
|
|
|
assert!(
|
|
|
|
text1 == text2,
|
|
|
|
"exprs are not equal:\n e = {:?}\n parsed = {:?}",
|
|
|
|
text1,
|
|
|
|
text2
|
|
|
|
);
|
2019-09-05 17:29:31 -05:00
|
|
|
}
|
2017-07-20 15:53:56 -05:00
|
|
|
});
|
|
|
|
}
|