rustdoc-json: Structured representation of attributes

[aDotInTheVoid]

Today, rustdoc-json presents attributes as a Vec<String>

rust/src/rustdoc-json-types/lib.rs

Lines 179 to 196 in 356f2d0

	/// Attributes on this item.
	///
	/// Does not include `#[deprecated]` attributes: see the [`Self::deprecation`] field instead.
	///
	/// Some attributes appear in pretty-printed Rust form, regardless of their formatting
	/// in the original source code. For example:
	/// - `#[non_exhaustive]` and `#[must_use]` are represented as themselves.
	/// - `#[no_mangle]` and `#[export_name]` are also represented as themselves.
	/// - `#[repr(C)]` and other reprs also appear as themselves,
	/// though potentially with a different order: e.g. `repr(i8, C)` may become `repr(C, i8)`.
	/// Multiple repr attributes on the same item may be combined into an equivalent single attr.
	///
	/// Other attributes may appear debug-printed. For example:
	/// - `#[inline]` becomes something similar to `#[attr="Inline(Hint)"]`.
	///
	/// As an internal implementation detail subject to change, this debug-printing format
	/// is currently equivalent to the HIR pretty-printing of parsed attributes.
	pub attrs: Vec<String>,

This means that users wanting to use these attributes (and not just display them) must implement a parser for these strings. It'd be nice if rustdoc exposed the semantics of the attribute, and not just the syntax.

This'd mean going from Vec<String> to Vec<Attr>, and adding some enum Attr with all the possible kinds of attribute. The exact details would require design work. See #137645 (comment) for more detail.

Possibly this should wait untill the state of rustc's own attribute system is more settled (#131229).

CC @jdonszelmann @obi1kenobi