rust/tests/ui-fulldeps/pprust-expr-roundtrip.rs

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

259 lines
9.9 KiB
Rust
Raw Normal View History

// run-pass
2017-07-20 15:53:56 -05:00
// ignore-cross-compile
// The general idea of this test is to enumerate all "interesting" expressions and check that
// `parse(print(e)) == e` for all `e`. Here's what's interesting, for the purposes of this test:
//
// 1. The test focuses on expression nesting, because interactions between different expression
// types are harder to test manually than single expression types in isolation.
//
// 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.
//
// 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
// using `while`, `if let`, and so on will likely work as well.
2017-07-20 15:53:56 -05:00
#![feature(rustc_private)]
extern crate rustc_ast;
2020-01-18 12:21:05 -06:00
extern crate rustc_ast_pretty;
extern crate rustc_data_structures;
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;
use rustc_ast::mut_visit::{self, visit_clobber, MutVisitor};
use rustc_ast::ptr::P;
use rustc_ast::*;
2020-01-18 12:21:05 -06:00
use rustc_ast_pretty::pprust;
use rustc_parse::new_parser_from_source_str;
2020-01-18 12:21:05 -06:00
use rustc_session::parse::ParseSess;
2020-01-01 17:01:07 -06:00
use rustc_span::source_map::FilePathMapping;
use rustc_span::source_map::{FileName, Spanned, DUMMY_SP};
2020-04-25 14:13:56 -05:00
use rustc_span::symbol::Ident;
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>> {
let src_as_string = src.to_string();
let mut p =
new_parser_from_source_str(ps, FileName::Custom(src_as_string.clone()), src_as_string);
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> {
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`.
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));
for kind in 0..=18 {
2017-07-20 15:53:56 -05:00
match kind {
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"));
iter_exprs(depth - 1, &mut |e| {
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,
})))
});
iter_exprs(depth - 1, &mut |e| {
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,
})))
});
}
2..=7 => {
let op = Spanned {
span: DUMMY_SP,
node: match kind {
2 => BinOpKind::Add,
3 => BinOpKind::Mul,
4 => BinOpKind::Shl,
5 => BinOpKind::And,
6 => BinOpKind::Or,
7 => 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)));
}
8 => {
2017-07-20 15:53:56 -05:00
iter_exprs(depth - 1, &mut |e| g(ExprKind::Unary(UnOp::Deref, e)));
}
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,
tokens: None,
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)));
}
10 => {
let decl = P(FnDecl { inputs: thin_vec![], output: FnRetTy::Default(DUMMY_SP) });
iter_exprs(depth - 1, &mut |e| {
g(ExprKind::Closure(Box::new(Closure {
binder: ClosureBinder::NotPresent,
capture_clause: CaptureBy::Value,
2022-12-26 04:48:54 -06:00
constness: Const::No,
asyncness: Async::No,
movability: Movability::Movable,
fn_decl: decl.clone(),
body: e,
fn_decl_span: DUMMY_SP,
fn_arg_span: DUMMY_SP,
})))
2017-07-20 15:53:56 -05:00
});
}
11 => {
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)));
}
12 => {
iter_exprs(depth - 1, &mut |e| g(ExprKind::Field(e, Ident::from_str("f"))));
}
13 => {
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))
});
}
14 => {
iter_exprs(depth - 1, &mut |e| {
g(ExprKind::AddrOf(BorrowKind::Ref, Mutability::Not, e))
});
}
15 => {
2017-07-20 15:53:56 -05:00
g(ExprKind::Ret(None));
iter_exprs(depth - 1, &mut |e| g(ExprKind::Ret(Some(e))));
}
16 => {
2018-03-18 19:54:56 -05:00
let path = Path::from_ident(Ident::from_str("S"));
g(ExprKind::Struct(P(StructExpr {
qself: None,
path,
2023-02-20 17:24:51 -06:00
fields: thin_vec![],
rest: StructRest::Base(make_x()),
})));
}
17 => {
2017-07-20 15:53:56 -05:00
iter_exprs(depth - 1, &mut |e| g(ExprKind::Try(e)));
}
18 => {
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)))
}
2017-07-20 15:53:56 -05:00
_ => panic!("bad counter value in iter_exprs"),
}
}
}
// Folders for manipulating the placement of `Paren` nodes. See below for why this is needed.
2017-07-20 15:53:56 -05: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>) {
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
}
}
/// `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,
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: AttrVec::new(),
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() {
rustc_span::create_default_session_globals_then(|| run());
}
fn run() {
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);
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
});
}