use String::from() instead of format!() macro to construct Strings.

[matthiaskrgr]

No description provided.

[rust-highfive]

r? @matthewjasper

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

[zackmdavis]

r? @zackmdavis

@bors r+ rollup

[bors]

📌 Commit f6b8876 has been approved by zackmdavis

[ExpHP]

What's the point of this? All of these format!s are next to other format!s, so they benefit from consistency; and they're all in cold code paths, so the performance gains are null.

[RalfJung]

Is this an efficiency question or a style question? (For the future, it'd be great if such questions could be answered in the PR description or commit message, which seem like a likely place someone will look if they want to find out why something got changed.)

If it is about efficiency, is there any reason format! on a string literal has to be less efficient? Seems easy enough to special-case in a macro.

If it is about style, I'd prefer if you could consider consistency: In the miri validator (librustc_mir/interpret/validity.rs), we generate quite a few error messages, and we consistently do that with format! as many of them need some formatting. Exactly one doesn't, and you changed it to String::from. Now this one error message stands out in the code because it is not consistent with what we do everywhere else, that looks really odd. String::from is also longer, and this this case I do not think it increases readability, either. I hope you don't mind that when I resolved a merge conflict between this PR and mine, I changed this back to format!.

EDIT: Oh, just saw @ExpHP raised the same question. :)

[zackmdavis]

@ExpHP @RalfJung I can't speak to @matthiaskrgr's intent, but I felt comfortable approving the PR on style grounds: note that Clippy has a warn-by-default useless_format lint. I'm optimistic about eventually making it easy to run Clippy/rustfmt/&c. in this repo (#53896) to minimize the amount of contributor/reviewer effort spent on style-wrangling.