Tracking Issue for Rust 2024: rustfmt enable `overflow_delimited_expr` about rust HOT 9 OPEN

rustdoc? do you mean rustfmt?

Woops yes, fixed

from rust.

It looks like there's no owner driving forward on an implementation, which we need by May 1. If there's no owner of this we should take it out of the style guide for 2024.

@calebcartwright Is this something you can own the implementation of? If not, is there an alternative owner?

from rust.

It looks like there's no owner driving forward on an implementation, which we need by May 1

Not objecting to this specific deadline, but also first I'm hearing of a May 1st date. Is there a communication channel I should be monitoring?

@calebcartwright Is this something you can own the implementation of? If not, is there an alternative owner?

Sure put my name down. I'm a little puzzled by the overall approach to tracking these, likely due to my own ignorance. The "implementation" is changing a boolean value, so for my own 0.02 this all feels a bit too detailed and granular 🤷

from rust.

Just want to bring up a caveat.

I don't know how well tested the rustfmt feature is. There may or may not be some behavior differences between the current implementation in rustfmt and the specified behavior in the style guide.

from rust.

rustdoc? do you mean rustfmt?

from rust.

I don't know how well tested the rustfmt feature is. There may or may not be some behavior differences between the current implementation in rustfmt and the specified behavior in the style guide.

looks like there are some tests in rustfmt. Given that overflow_delimited_expr is still unstable I think it wouldn't hurt to double check that the implementation matches what's described in the style guide and maybe add some extra test cases.

from rust.

@pitaj I believe the formatting issues you brought up in #114764 (comment) and #114764 (comment) are still issues for rustfmt unless this is the correct formatting based on the style guide:

running with overflow_delimited_expr=true

fn main() {
vbuf.write(i * 3, Bar(
    Foo { x: 1, y: 2, z: 3 },
    Foo { x: 1, y: 2, z: 3 },
    Foo { x: 1, y: 2, z: 3 },
));

vbuf.write(i + 3, &[
    [h - 0.1, v],
    [h - 0.1, v],
    [h - 0.1, v],
    [h - 0.1, v],
]);
}

into

fn main() {
    vbuf.write(
        i * 3,
        Bar(Foo { x: 1, y: 2, z: 3 }, Foo { x: 1, y: 2, z: 3 }, Foo {
            x: 1,
            y: 2,
            z: 3,
        }),
    );

    vbuf.write(i + 3, &[[h - 0.1, v], [h - 0.1, v], [h - 0.1, v], [
        h - 0.1,
        v,
    ]]);
}

from rust.

I consider those cases unfortunate, but they actually do match the behavior as currently specified by the style guide.

I did try my hand at writing up a policy to adjust for those, but it wasn't included in the end.

I think users can use comments to force specific formatting in those cases.

from rust.

How common are those cases? I can image that some users might find this formatting worse than overflow_delimited_expr=false.

@calebcartwright I know that technically the implementation is as simple as flipping a boolean to enable this by default, but I'd also want to stabilize overflow_delimited_expr at the same time so users at least have the option to turn this off.

from rust.