ty: remove obsolete pretty printer

[davidtwco]

Fixes#61139.

This PR removes the obsolete printer and replaces all uses of it with FmtPrinter. Of the replaced uses, all but one use was in debug! logging, two cases were notable:

• MonoItem::to_string is used in -Z print-mono-items and therefore affects the output of all codegen-units tests (which have been updated).
• DefPathBasedNames was used in librustc_codegen_llvm/type_of.rs with LLVMStructCreateNamed and that'll now get different values, but nothing will break as a result of this.

cc @eddyb (whom I've discussed this with)

[rust-highfive]

r? @eddyb

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

[eddyb]

cc @oli-obk@nikomatsakis (for the changes in codegen-units tests - which should probably be made into UI tests tbh)

Would be neat if we could have @michaelwoerister take a quick look to tell us if we're off the mark here, but likely won't happen.

[eddyb]

r=me on the implementation (not sure if you want to wait for someone to give their opinion on the incremental tests? they seem fine to me, at least)

[davidtwco]

@bors r=eddyb

[bors]

📌 Commit 032408fdfe71597546141dbe89b6213d90d43062 has been approved by eddyb

[davidtwco]

@bors r=eddyb (rebase was only after #74862)

[bors]

📌 Commit 6ff471b has been approved by eddyb

[bors]

⌛ Testing commit 6ff471b with merge 8ed5cb5...

[bors]

☀️ Test successful - checks-actions, checks-azure
Approved by: eddyb
Pushing 8ed5cb5 to master...

[rust-highfive]

📣 Toolstate changed by #76027!

Tested on commit 8ed5cb5.
Direct link to PR: #76027

💔 rls on windows: test-pass → build-fail (cc @Xanewok).
💔 rls on linux: test-pass → build-fail (cc @Xanewok).
💔 rustfmt on windows: test-pass → build-fail (cc @topecongiro@calebcartwright).
💔 rustfmt on linux: test-pass → build-fail (cc @topecongiro@calebcartwright).

[ecstatic-morse]

This caused a rather large regression that seems to have been fixed in #76030 (results). Overall the net result was a small improvement on optimized and debug builds. Is all of this meeting expectations @davidtwco?

[davidtwco]

This caused a rather large regression that seems to have been fixed in #76030 (results). Overall the net result was a small improvement on optimized and debug builds. Is all of this meeting expectations @davidtwco?

I wasn't expecting quite as large a regression, but it makes sense that the other PR would result in a net improvement.

[ecstatic-morse]

Asked another way, is it possible to get the benefits of the second PR without the regression from this one?

[davidtwco]

Asked another way, is it possible to get the benefits of the second PR without the regression from this one?

Yes, you could just revert this.

The second PR adds a early exit which skips the pretty printer for one case (with this PR, it skips the new slower printer, without it skips the old faster printer) - given that this case is most common, it claws most of the performance back. In either case, the impact is really only felt by incremental compilation where the difference is a larger proportion of the overall execution.

I think we’d only see a small improvement from reverting this because the second PR isn’t making this change faster, it’s skipping it and it would be skipping what was there prior to this landing.