rustdoc HTML shouldn't rely on HIR pretty-printing for attributes

[fmease]

Oh no :( The rustdoc HTML backend shouldn't use HIR pretty-printing at all. Fortunately, rustdoc only displays a fixed set of attrs: export_name, link_section, no_mangle, non_exhaustive and repr but for repr we don't rely on HIR pretty-printing.

Using HIR pretty is busted anyway, since it doesn't escape HTML. E.g., #[unsafe(link_section = "<script>alert()</script>")] triggers an alert.

Originally posted by @fmease in #142823 (comment)

[fmease]

It also fails to render the #[unsafe(…)] for unsafe attributes. Well, should we actually render that? 🤔 The unsafe is a notice for the library author not the consumer.

[obi1kenobi]

While rustdoc JSON is still pretty-printing arguments too (and until it starts reporting structured attribute information instead), I think the same pretty-printing code path here (except for repr, as previously discussed) should apply to JSON too.

I think #[unsafe(..)] should be printed. As a reader of HTML docs, I would expect the attributes I see in HTML to be valid latest-edition Rust. That means I'd expect #[unsafe(no_mangle)] not #[no_mangle].

For example, imagine a new Rustacean who just started learning Rust circa Rust 1.86. They shouldn't have to know that #[unsafe(..)] didn't use to exist, and they'd be confused by seeing #[no_mangle] which their editor would inform them is not valid Rust.

[fmease]

I would expect the attributes I see in HTML to be valid latest-edition Rust

Yea I fully agree. We're going to do the same with impl Trait / use<>, see #135453