Preserve span when lowering ExprKind::Paren

[sanxiyn]

Fix#33681.

[rust-highfive]

r? @nikomatsakis

(rust_highfive has picked a reviewer for you, use r? to override)

[nikomatsakis]

@bors r+ rollup

[bors]

📌 Commit 0f257df has been approved by nikomatsakis

[Manishearth]

@bors r- , fails travis

failures:
[compile-fail] compile-fail/associated-const-private-impl.rs
[compile-fail] compile-fail/issue-2392.rs
[compile-fail] compile-fail/private-struct-field-cross-crate.rs
[compile-fail] compile-fail/private-struct-field.rs
test result: FAILED. 2237 passed; 4 failed; 11 ignored; 0 measured

[sanxiyn]

This is trickier than I thought. The problem is illustrated by the following code:

macro_rules! paren {($e:expr) => (($e))}mod m {pubstructS{x:i32}pubfnmake() -> S{S{x:0}}}fnmain(){let s = m::make();paren!(s.x);}

Before:

error: field `x` of struct `m::S` is private
--> test.rs:16:12
16 |> paren!(s.x);
|> ^^^

After:

error: field `x` of struct `m::S` is private
--> test.rs:2:19
2 |> ($e:expr) => (($e))
|> ^^^^

[sanxiyn]

Since Rust macro is not text substitution, there is never a need to parenthesize like ($e), unlike in C. Still, assert_eq! does that. By the way, why do we have assert_eq! in compile-fail tests?!

[nikomatsakis]

@sanxiyn

By the way, why do we have assert_eq! in compile-fail tests?!

Why wouldn't we?

Still, assert_eq! does that.

Hmm. So... it seems like your highlighting code was doing the right thing, but perhaps assert_eq ought to be modified. I guess we can expect other macros to get suboptimal highlighting in a similar fashion.

[sanxiyn]

Modified assert_eq!. Now passes cfail locally.

[sanxiyn]

Now suboptimal highlighting is avoided.

[nikomatsakis]

@bors r+ rollup

I'm not sure which is better, but this seems good too.

[bors]

📌 Commit edf1773 has been approved by nikomatsakis