Do not deduplicate captured args while expanding format_args!

[ShoyuVanilla]

Resolves #145739

I ran crater with #149291.
While there are still a few seemingly flaky, spurious results, no crates appear to be affected by this breaking change.

The only hit from the lint was
https://github.com/multiversx/mx-sdk-rs/blob/813927c03a7b512a3c6ef9a15690eaf87872cc5c/framework/meta-lib/src/tools/rustc_version_warning.rs#L19-L30,
which performs formatting on consts of type ::semver::Version. These constants contain a nested ::semver::Identifier (Version.pre.identifier) that has a custom destructor. However, this case is not impacted by the change, so no breakage is expected.

[rustbot]

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

Some changes occurred in compiler/rustc_ast_lowering/src/format.rs

cc @m-ou-se

[rustbot]

r? @spastorino

rustbot has assigned @spastorino.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[ShoyuVanilla]

@rustbot author

[ShoyuVanilla]

@rustbot ready

[theemathas]

Nominating as per #145739 (comment)

[traviscross]

It'd be worth adding a test for the drop behavior.

[traviscross]

Given that this makes more sense for the language, along with the clean crater results and the intuition that it'd be surprising if anything actually leaned on this, I propose:

@rfcbot fcp merge lang

[rust-rfcbot]

Team member @traviscross has proposed to merge this. The next step is review by the rest of the tagged team members:

• @joshtriplett
• @nikomatsakis
• @scottmcm
• @tmandry
• @traviscross

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[m-ou-se]

I don't think we should do this. It will make the generated code for println!("{x} {x}"); less efficient, as it will get two separate arguments instead of one.

I don't want to end up in a situation where it would make sense for Clippy to suggest something like:

warning: using the same placeholder multiple times is inefficient as of Rust 1.94.0
 --> src/main.rs:3:5
  |
3 |     println!("{x} {x}");
  |     ^^^^^^^^^^^^^^^^^^^
  |
help: change this to
  |
3 -     println!("{x} {x}");
3 +     println!("{x} {x}", x = x);
  |

Adding , x = x shouldn't make a difference. If adding that makes the resulting code more efficient, I strongly feel like we've done something wrong.

@rust-rfcbot concern equivalence

[m-ou-se]

I don't think using the same variable multiple times in a format string is common enough [..]

I think that situation is quite common actually. E.g.

println!("Accepted: {n_accepted}/{n_total}, Rejected: {n_rejected}/{n_total}");

format!("ip link {interface} down && ip link {interface} up");

println!("{indent}line 1\n{indent}line 2");

error!("Feature `{feature}` not enabled. To enable {feature}, add `#![feature({feature})]`.");

warn!("Integer literal out of range for {ty}. The range of {ty} is {min}{ty}..={max}{ty}.");

[workingjubilee]

The RFC specifically says that it should be equivalent to format_args!("{name}", name = name).

https://rust-lang.github.io/rfcs/2795-format-args-implicit-identifiers.html

[theemathas]

@workingjubilee This has been previously discussed at #145739 (comment)

[workingjubilee]

Yes, I'm stating that throwing out this equivalence because of wonkiness when using things that are often specifically highlighted as notoriously bad ideas is a bad idea.

[traviscross]

Could we get what we want as a lang matter and keep most of the optimization benefit by doing the optimization only when it's guaranteed to not be observable, e.g. when values of the type don't need to be dropped and can't be interior mutable? Is that feasible?

[dianne]

Could we get what we want as a lang matter and keep most of the optimization benefit by doing the optimization only when it's guaranteed to not be observable, e.g. when values of the type don't need to be dropped and can't be interior mutable? Is that feasible?

I don't think there's much we can do about pathological Debug or Display impls that make it observable when something is formatted. In general, that doesn't even require interior mutability. Rust's type system just isn't equipped to reason about it; we don't have pure functions. I think the best we could get is to treat derived impls as trusted if fields' impls are trusted and do a pass where we mess with how format_args! expands based on whether we can prove formatting doesn't execute any untrusted code. But that leaves a lot of uses unoptimized and it's overengineered if all it's solving is this.

If we're only concerned with how many drop-sensitive temporaries are created, this is much easier to solve. We could optimize in the most common case (multiple mentions of local variables in a formatting string) without even needing type information when expanding format_args!, since taking a reference to a variable won't create a temporary; it's just named constants and nullary constructors where that can be an issue.

[jackh726]

I'm just gonna initiate a perf run to just see if there is any observable regressions under the current changes (though, recognizing a negative signal here is not super meaningful).

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[traviscross]

@rfcbot fcp cancel

[rust-rfcbot]

@traviscross proposal cancelled.

[traviscross]

@rfcbot fcp merge lang,libs-api

[rust-rfcbot]

Team member @traviscross has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @nikomatsakis
• @scottmcm
• @the8472
• @tmandry
• @traviscross

Concerns:

• equivalence (Do not deduplicate captured args while expanding format_args! #149926 (comment))

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[BurntSushi]

I shared @m-ou-se's concern from above:

I don't think we should do this. It will make the generated code for println!("{x} {x}"); less efficient, as it will get two separate arguments instead of one.

I don't want to end up in a situation where it would make sense for Clippy to suggest something like:

warning: using the same placeholder multiple times is inefficient as of Rust 1.94.0
 --> src/main.rs:3:5
  |
3 |     println!("{x} {x}");
  |     ^^^^^^^^^^^^^^^^^^^
  |
help: change this to
  |
3 -     println!("{x} {x}");
3 +     println!("{x} {x}", x = x);
  |

Adding , x = x shouldn't make a difference. If adding that makes the resulting code more efficient, I strongly feel like we've done something wrong.

@rfcbot concern equivalence

[traviscross]

@BurntSushi, @the8472, perhaps you could speak to the suggestion that we can optimize things at other layers, e.g. as @dianne described:

If we're only concerned with how many drop-sensitive temporaries are created, this is much easier to solve. We could optimize in the most common case (multiple mentions of local variables in a formatting string) without even needing type information when expanding format_args!, since taking a reference to a variable won't create a temporary; it's just named constants and nullary constructors where that can be an issue.

[traviscross]

Also, could you both speak to whether, for these optimization reasons, you'd similarly expect that we would desugar format_args!("{x.f} {x.f}") as format_args!("{0} {0}", x.f)? For format_args!("{x.y} {x.y.z}"), what desugaring would you expect?

[rust-bors]

☀️ Try build successful (CI)
Build commit: 0282858 (0282858611f50e7d4c722e4a5295fc552f7236a1, parent: 625b63f9e148d511e187c71e5f70643ee62c77fb)

[rust-timer]

Queued 0282858 with parent 625b63f, future comparison URL.
There are currently 0 preceding artifacts in the queue.
It will probably take at least ~1.0 hours until the benchmark run finishes.

[the8472]

It's more that my expectation is that these ought to be pure and we should optimize accordingly. And I haven't seen anyone making the argument that real-world code actually expects or relies on side-effects happening in print expressions, so why should we go out of our way to make code less efficient to enable something nobody needs?

We could optimize in the most common case (multiple mentions of local variables in a formatting string) without even needing type information when expanding format_args!, since taking a reference to a variable won't create a temporary

I guess that'd be fine, yeah.

[RalfJung]

We already enabled that -- you can have drop glue in consts, and you can print consts. So the question is, do we have nice regular behavior or do we add weird exceptions to the semantics of the language?

[the8472]

Arguably macros are not semantics of the language, but arbitrary stuff a macro does to rewrite your code, no?

[RalfJung]

Insofar as format_args is a builtin macro, its behavior is part of the language.