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

[fmease]

The call to rustc_hir_pretty::attribute_to_string has already been removed in #142936, though it builds on earlier works by different authors who ported the relevant attributes to the new API.

So apart from the fact that these literals are still not escaped this issue has been addressed. I'll add the escaping logic to #116882 but I might split it out of it since it's still unclear if it'll actually land (the FCP is still only proposed).