Code within stringify!(...) and assert_eq!(...) not being formatted very well

[fitzgen]

input.rs:

# [ test ] fn __bindgen_test_layout_HandleWithDtor_open0_int_close0_instantiation ( ) { assert_eq ! ( :: std :: mem :: size_of :: < HandleWithDtor < :: std :: os :: raw :: c_int > > ( ) , 8usize , concat ! ( "Size of template specialization: " , stringify ! ( HandleWithDtor < :: std :: os :: raw :: c_int > ) ) ) ; assert_eq ! ( :: std :: mem :: align_of :: < HandleWithDtor < :: std :: os :: raw :: c_int > > ( ) , 8usize , concat ! ( "Alignment of template specialization: " , stringify ! ( HandleWithDtor < :: std :: os :: raw :: c_int > ) ) ) ; }

Run rustfmt:

$ rustup run nightly rustfmt --version
0.2.2-nightly ( )
$ rustup run nightly rustfmt < input.rs > output.rs

And here is output.rs:

#[test]
fn __bindgen_test_layout_HandleWithDtor_open0_int_close0_instantiation() {
    assert_eq!(
        ::std::mem::size_of::<HandleWithDtor<::std::os::raw::c_int>>(),
        8usize,
        concat!(
            "Size of template specialization: ",
            stringify ! ( HandleWithDtor < :: std :: os :: raw :: c_int > )
        )
    );
    assert_eq ! ( :: std :: mem :: align_of :: < HandleWithDtor < :: std :: os :: raw :: c_int > > ( ) , 8usize , concat ! ( "Alignment of template specialization: " , stringify ! ( HandleWithDtor < :: std :: os :: raw :: c_int > ) ) );
}

Note that ::std::os::raw::c_int still has a bunch of spaces between tokens, as do the actual macro invocations, eg stringify ! ( ... ) instead of stringify!(...).

[fitzgen]

Also, thanks for the quick responses to my other issues filed :)

[nrc]

Hmm, stringify might not be parsing as a function call, but assert_eq looks like it should, it could be the nested macros, but then, I'd expect the first assert_eq not to format either.

[topecongiro]

Hmm, stringify might not be parsing as a function call, but assert_eq looks like it should, it could be the nested macros, but then, I'd expect the first assert_eq not to format either.

I think this is hitting the same issue as #1742.