r? @nikomatsakis

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

@bors r+ rollup

📌 Commit 0f257df has been approved by nikomatsakis

@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

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

macro_rules! paren {
    ($e:expr) => (($e))
}

mod m {
    pub struct S {
        x: i32
    }
    pub fn make() -> S {
        S { x: 0 }
    }
}

fn main() {
    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))
  |>                   ^^^^

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?!

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

Modified assert_eq!. Now passes cfail locally.

Now suboptimal highlighting is avoided.

@bors r+ rollup

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

📌 Commit edf1773 has been approved by nikomatsakis