There is no longer a need to append the string `", ..."` to a functions
args as `...` is parsed as an argument and will appear in the functions
arguments.
Joshua Netterfield reported an ICE when the unused-parentheses lint
triggered around an async block (#54752). In order to compose an
autofixable suggestion, the lint invokes the pretty-printer on the
unnecessarily-parenthesized expression. (One wonders why the lint
doesn't just use `SourceMap::span_to_snippet` instead, to preserve the
formatting of the original source?—but for that, you'd have to ask the
author of 5c9f806d.)
But then the pretty-printer panics when trying to call `<pprust::State
as PrintState>::end` when `State.boxes` is empty. Empirically, the
problem would seem to be solved if we start some "boxes" beforehand in
the `ast::ExprKind::Async` arm of the big match in
`print_expr_outer_attr_style`, exactly like we do in the
immediately-preceding match arm for `ast::ExprKind::Block`—it would
seem pretty ("pretty") reasonable for the pretty-printing of async
blocks to work a lot like the pretty-printing of ordinary non-async
blocks, right??
Of course, it would be shamefully cargo-culty to commit code on the
basis of this kind of mere reasoning-by-analogy (in contrast to
understanding the design of the pretty-printer in such detail that the
correctness of the patch is comprehended with all the lucid certainty
of mathematical proof, rather than being merely surmised by
intuition). But maybe we care more about fixing the bug with high
probability today, than with certainty in some indefinite hypothetical
future? Maybe the effort is worth a fifth of a shirt??
Humbly resolves#54752.
Pretty print parens around casts on the LHS of `<`/`<<`
When pretty printing a cast expression occuring on the LHS of a `<` or `<<` expression, we should add parens around the cast. Otherwise, the `<`/`<<` gets interpreted as the beginning of the generics for the type on the RHS of the cast.
Consider:
$ cat parens_cast.rs
macro_rules! negative {
($e:expr) => { $e < 0 }
}
fn main() {
negative!(1 as i32);
}
Before this PR, the output of the following is not valid Rust:
$ rustc -Z unstable-options --pretty=expanded parens_cast.rs
#![feature(prelude_import)]
#![no_std]
#[prelude_import]
use std::prelude::v1::*;
#[macro_use]
extern crate std as std;
macro_rules! negative(( $ e : expr ) => { $ e < 0 });
fn main() { 1 as i32 < 0; }
After this PR, the output of the following is valid Rust:
$ rustc -Z unstable-options --pretty=expanded parens_cast.rs
#![feature(prelude_import)]
#![no_std]
#[prelude_import]
use std::prelude::v1::*;
#[macro_use]
extern crate std as std;
macro_rules! negative(( $ e : expr ) => { $ e < 0 });
fn main() { (1 as i32) < 0; }
I've gone through several README/wiki style documents but I'm still not sure where to test this though. I'm not even sure if this sort of thing is tested...
