Specialize ToString implementation for fmt::Arguments

[DaniPopes]

Generates far fewer instructions by formatting into a String with fmt::format directly instead of going through the fmt::Display impl. This change is insta-stable.

[rustbot]

r? @Mark-Simulacrum

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

[rustbot]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[DaniPopes]

@rustbot label +T-libs-api -T-libs

[Mark-Simulacrum]

What is the user-visible impact of this specialization? Naively it seems like it should just be an internal optimization?

@rustbot author

[DaniPopes]

Having generic std::fmt::Display or ToString arguments is a pretty common pattern, and this would allow format_args! to be more efficient than format! when ToString::to_string is called on it.

This is somewhat how I found that it was not specialized:

enum Error {
    Custom(String),
}

impl Error {
    //  or T: ToString
    fn new<T: std::fmt::Display>(t: T) -> Self {
        Self::Custom(t.to_string())
    }
}

fn main() {
    let stuff = 1234;
    let _a = Error::new(stuff);
    let _b = Error::new(format_args!("Format args: {stuff}"));
    let _c = Error::new(format!("Format: {stuff}"));
    let _d = Error::new("Str");
}

Using format! here formats into a string, passes it by value and then clones it, while format_args! formats only at the end in the ToString call, while also avoiding a clone.
This is obviously a very minor thing here but I'm sure there are other cases where format_args! is used over format!, or when lazily formatting is preferred, like in custom write!/print!-like macros.

[Mark-Simulacrum]

When I say user visible I mean e.g. a test case that would fail before this change, but works after, or similar. If this is purely about performance then that's generally easier to land, as it's not something we would be blocked on reverting if we decide to go a different path in the future.

[DaniPopes]

Oh sorry, I misunderstood your question. Yes, this is purely about performance, similar to #106662 and #82576, and can be undone in the future.

[DaniPopes]

@rustbot review

[Mark-Simulacrum]

@bors r+ rollup

I think this is reasonable and should be silently removable down the line (i.e., is not a stability promise).

cc @m-ou-se as well since you're working on formatting optimizations

[bors]

📌 Commit fd80ab7 has been approved by Mark-Simulacrum

It is now in the queue for this repository.