Tracking Issue for Rust 2024: rustfmt enable overflow_delimited_expr

[traviscross]

This is a tracking issue for the Rust 2024-relevant parts of:

• [style edition 2024] Combine all delimited exprs as last argument #114764
• [unstable option] overflow_delimited_expr rustfmt#3370

This issue is for tracking readiness for the Rust 2024 edition.

About tracking issues

Tracking issues are used to record the overall progress of implementation. They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

• Implement in nightly Rust 2024.
  • implement 2024 expression overflowing rustfmt#6260
• Add documentation to the edition guide.
  • 2024: Document rustfmt overflow_delimited_expr edition-guide#352
• Add formatting for new syntax to the style guide.
  • [style edition 2024] Combine all delimited exprs as last argument #114764
  • See the nightly style procedure.
• Ensure ready for Rust 2024 stabilization.

cc @rust-lang/style @rust-lang/rustfmt @calebcartwright @pitaj

[tmandry]

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?

[calebcartwright]

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 🤷

[pitaj]

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.

[ytmimi]

rustdoc? do you mean rustfmt?

[pitaj]

rustdoc? do you mean rustfmt?

Woops yes, fixed

[ytmimi]

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.

[ytmimi]

@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,
    ]]);
}

[pitaj]

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.

[ytmimi]

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.

[joshtriplett]

@pitaj wrote:

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

I don't think I've seen that, and I'd love to. This is still an area I'd love to further improve in future style editions, along with the "this is simple" heuristics.

[pitaj]

My attempt: b754b33

[ia0]

I'd like to suggest another attempt to the one of @pitaj (which I guess could be summarized by "stop recursion if the last 2 elements of the current list are of the same kind, e.g. both arrays, both tuples, etc").

This overflow_delimited_expr feature has a notion of recursion through the nesting of list-like syntax. I suggest looking at the height of this nesting to decide when to stop recursion. I define the height of a list as one plus the maximum height of its elements (zero if there are none). Recursion through the last element should stop if there is another element (in that list) with a greater or equal height as that last element. Equivalently, recursion should continue if the last element has the greatest (unmatched) height in the list. Here are some formatted examples with explanations:

// `write()` elements: we recurse because the last one has a height of 2
//     which is greater than all other elements (`i * 3` has a height of 1).
// `Bar` elements: we stop recursion because all elements have a height of 1,
//     so the last one does not have a height greater than all other elements.
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 },
));
// Same reasoning here. The last element of `Bar` has a height matched by the first element.
vbuf.write(i * 3, Bar(
    Foo { x: 1, y: 2, z: 3 },
    42,
    Foo { x: 1, y: 2, z: 3 },
));
// Now, the last element of `Bar` has the greatest unmatched height, so we recurse.
// `Foo` elements: They all have the same height, so we don't recurse (anyway, 3 is not a list).
vbuf.write(i * 3, Bar(13, 42, Foo {
    x: 1,
    y: 2,
    z: 3,
}));

[joshtriplett]

That seems like a very reasonable heuristic!

How easily could you run rustfmt with that heuristic over the rust-lang/rust codebase, and push that to a branch somewhere for review? That'd make it easy to see whether on balance it seems to be an improvement.

[traviscross]

@rustbot labels -S-tracking-needs-documentation +S-tracking-ready-for-edition

Given that this was documented (thanks @ehuss) in:

• 2024: Document rustfmt overflow_delimited_expr edition-guide#352

This item is now ready for Rust 2024. Thanks to @calebcartwright, @ytmimi, and the rest of the rustfmt and style teams for pushing this forward.