Pretty print parens around casts on the LHS of </<<

[harpocrates]

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...

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nikomatsakis (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[kennytm]

I'm not even sure if this sort of thing is tested...

You could add a test case to src/test/pretty. Refer to src/test/pretty/issue-4264.{rs,pp} as an example.

[harpocrates]

You could add a test case to src/test/pretty. Refer to src/test/pretty/issue-4264.{rs,pp} as an example.

I'm confused.

I thought that those tests do (roughly) the following: parse, pretty-print, re-parse, and check that the first and last of these are the same. However, this issue occurs only when synthetically (either through a macro or by using rustc's internals) creating ASTs and then pretty-printing them...

Help?

[kennytm]

@harpocrates No problem.

If you check issue-4264.rs you'll find the following lines:

// pretty-compare-only
// pretty-mode:hir,typed
// pp-exact:issue-4264.pp

The middle line instructs the test runner to pass --unpretty hir,typed when running rustc. So in your case, you'd want to include the following in the *.rs file:

// pretty-compare-only
// pretty-mode:expanded
// pp-exact:******.pp

and then copy the --unpretty=expanded output to the *.pp file.

[kennytm]

LGTM. Some minor nits.

[kennytm]

2017

[harpocrates]

Good point! :)

[kennytm]

Remove this comment.

[harpocrates]

Derp. Fixed now.

[kennytm]

Thanks.

@bors r+

[bors]

📌 Commit 3761c0d has been approved by kennytm

[kennytm]

@bors r-

[kennytm]

You haven't removed this from the *.pp file...

[harpocrates]

I'm so sorry! I'll be more careful next time... :S

[kennytm]

@bors r+

[bors]

📌 Commit aa38a1e has been approved by kennytm