Multiple references to a single footnote is a part of GitHub Flavored
Markdown syntax (although not explicitly documented as well as regular
footnotes, it is implemented in GitHub's fork of CommonMark) and not
prohibited by rustdoc.
cf. <587a12bb54/test/extensions.txt (L762-L780)>
However, using it makes multiple "sup" elements with the same "id"
attribute, which is invalid per the HTML specification.
Still, not only this is a valid GitHub Flavored Markdown syntax, this is
helpful on certain cases and actually tested (accidentally) in
tests/rustdoc/footnote-reference-in-footnote-def.rs.
This commit keeps track of the number of references per footnote and gives
unique ID to each reference. It also emits *all* back links from a footnote
to its references as "↩" (return symbol) plus a numeric list in superscript.
As a known limitation, it assumes that all references to a footnote are
rendered (this is not always true if a dangling footnote has one or more
references but considered a reasonable compromise).
Also note that, this commit is designed so that no HTML changes will occur
unless multiple references to a single footnote is actually used.
[rustdoc] Display unsafe attrs with edition 2024 `unsafe()` wrappers.
Use Rust 2024 edition representation for unsafe attributes in rustdoc HTML:
- `#[no_mangle]` -> `#[unsafe(no_mangle)]`
- `#[export_name = "foo"]` -> `#[unsafe(export_name = "foo")]`
- `#[link_section = ".text"]` -> `#[unsafe(link_section = ".text")]`
The 2024 edition representation is used regardless of the crate's own edition. This ensures that Rustaceans don't have to learn the rules of an outdated edition (e.g. that `unsafe()` wasn't always necessary) in order to understand a crate's documentation.
After some looking through the `T-rustdoc` issues, I was not able to find an existing issue for this. Apologies if I missed it.
r? ``````@aDotInTheVoid``````
Fix rustdoc not correctly showing attributes on re-exports
Fixes attributes not being shown correctly in rustdoc on re-exports
Does this need to be backported to beta?
r? ``@jdonszelmann``
Add regression test for #137857 to ensure that we generate intra doc links for extern crate items.
Fixes https://github.com/rust-lang/rust/issues/137857.
I checked that linking to extern crates was generating valid links (with the `/index.html` part) and since it's already working, just adding a regression test.
r? `@notriddle`
rustdoc: show attributes on enum variants
mostly for #[non_exhaustive]
unsure if there's any attributes we should take care to *not* include, it could use `render_code_attribute` and `is_non_exhaustive` instead, if that is a concern.
fixesrust-lang/rust#142599
New const traits syntax
This PR only affects the AST and doesn't actually change anything semantically.
All occurrences of `~const` outside of libcore have been replaced by `[const]`. Within libcore we have to wait for rustfmt to be bumped in the bootstrap compiler. This will happen "automatically" (when rustfmt is run) during the bootstrap bump, as rustfmt converts `~const` into `[const]`. After this we can remove the `~const` support from the parser
Caveat discovered during impl: there is no legacy bare trait object recovery for `[const] Trait` as that snippet in type position goes down the slice /array parsing code and will error
r? ``@fee1-dead``
cc ``@nikomatsakis`` ``@traviscross`` ``@compiler-errors``
Merge `Cfg::render_long_html` and `Cfg::render_long_plain` methods common code
Follow-up of https://github.com/rust-lang/rust/pull/141747.
Thanks `@camelid` for spotting it!
r? `@camelid`
rustdoc: linking to a local proc macro no longer warns
fixes https://github.com/rust-lang/rust/issues/91274
tried to keep the fix general in case we ever have any other kind of item that occupies
multiple namespaces simultaniously.
