summary refs log tree commit diff
path: root/src/librustdoc
AgeCommit message (Collapse)AuthorLines
2025-05-09Remove `Ident::empty`.Nicholas Nethercote-7/+16
All uses have been removed. And it's nonsensical: an identifier by definition has at least one char. The commits adds an is-non-empty assertion to `Ident::new` to enforce this, and converts some `Ident` constructions to use `Ident::new`. Adding the assertion requires making `Ident::new` and `Ident::with_dummy_span` non-const, which is no great loss. The commit amends a couple of places that do path splitting to ensure no empty identifiers are created.
2025-05-08Rollup merge of #140762 - aDotInTheVoid:popnl, r=GuillaumeGomezMatthias Krüger-1/+5
rustdoc-json: Remove newlines from attributes Fixes #140689 Not sure if this needs to bump `FORMAT_VERSION` or not. r? ``@GuillaumeGomez`` cc ``@obi1kenobi``
2025-05-07rustdoc-json: Remove newlines from attributesAlona Enraght-Moony-1/+5
2025-05-07Rollup merge of #140706 - GuillaumeGomez:fix-missing-temp-dir-cleanup, ↵Guillaume Gomez-3/+21
r=notriddle [rustdoc] Ensure that temporary doctest folder is correctly removed even if doctests failed Fixes #139899. The bug was due to the fact that if any doctest fails for any reason, we call `exit` (or it's called inside `libtest` if not edition 2024), meaning that `TempDir`'s destructor isn't called, and therefore the temporary folder isn't cleaned up. Took me a while to figure out how to reproduce but finally I was able to reproduce the bug with: `````rust #![doc(test(attr(deny(warnings))))] //! ``` //! let a = 12; //! ``` ````` And then I ensured that panicking doctests were cleaned up as well: `````rust //! ``` //! panic!(); //! ``` ````` And finally I checked if it was fixed for merged doctests too (`--edition 2024`). To make this work, I needed to add a new public function in `libtest` too which would call a function once all tests have been run. So only issue is: I have absolutely no idea how we can add a regression test for this fix. If anyone has an idea... r? `@notriddle`
2025-05-06rustdoc: remove unportable markdown lint and old parserMichael Howell-159/+1
Follow up https://github.com/rust-lang/rust/pull/127127
2025-05-06Ensure that temporary doctest folder is correctly removed even if doctests ↵Guillaume Gomez-3/+21
failed
2025-05-06Rollup merge of #140135 - GuillaumeGomez:sidebars-image, r=rustdocGuillaume Gomez-21/+22
Unify sidebar buttons to use the same image Part of https://github.com/rust-lang/rust/issues/139832. The source sidebar looks like this with the new image: ![image](https://github.com/user-attachments/assets/df4fee52-fb71-4794-91b7-3afc6d2aab70) You can test it [here](https://rustdoc.crud.net/imperio/sidebar-images/src/foo/foo.rs.html). r? `@notriddle`
2025-05-06Rollup merge of #140035 - fee1-dead-contrib:push-oszwkkvmpkks, ↵Stuart Cook-2/+4
r=jieyouxu,wesleywiser Implement RFC 3503: frontmatters Tracking issue: #136889 Supercedes #137193. This implements [RFC 3503](https://github.com/rust-lang/rfcs/blob/master/text/3503-frontmatter.md). This might break rust-analyzer. Will look into how to fix that. Suggestions welcome for how to improve diagnostics.
2025-05-05Implement RFC 3503: frontmattersDeadbeef-2/+4
Supercedes #137193
2025-05-03Allow linking rustc and rustdoc against the same single tracing crateDavid Tolnay-5/+21
By consecutively initializing `tracing` and `rustc_log`, Rustdoc assumes that these involve 2 different tracing crates. I would like to be able to build rustdoc against the same tracing crate that rustc_log is also built against. Previously this arrangement would crash rustdoc: thread 'main' panicked at rust/compiler/rustc_log/src/lib.rs:142:65: called `Result::unwrap()` on an `Err` value: SetGlobalDefaultError("a global default trace dispatcher has already been set") stack backtrace: 0: rust_begin_unwind 1: core::panicking::panic_fmt 2: core::result::unwrap_failed 3: rustc_log::init_logger 4: rustc_driver_impl::init_logger 5: rustdoc::main note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. error: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-rustdoc&template=ice.md note: please make sure that you have updated to the latest nightly query stack during panic: end of query stack
2025-05-01rustdoc: Fix doctest heuristic for main fn wrappingLeón Orell Valerian Liehr-37/+28
2025-04-28Rollup merge of #140316 - nnethercote:BoxMarker, r=dtolnayGuillaume Gomez-4/+4
Introduce `BoxMarker` to improve pretty-printing correctness Box opening/closing is really easy to get wrong in the pretty-printers. This PR makes it much harder to get wrong. r? `@Urgau`
2025-04-28Rollup merge of #140249 - BoxyUwU:remove_weak_alias_terminology, r=oli-obkGuillaume Gomez-2/+2
Remove `weak` alias terminology I find the "weak" alias terminology to be quite confusing. It implies the existence of "strong" aliases (which do not exist) and I'm not really sure what about weak aliases is "weak". I much prefer "free alias" as the term. I think it's much more obvious what it means as "free function" is a well defined term that already exists in rust. It's also a little confusing given "weak alias" is already a term in linker/codegen spaces which are part of the compiler too. Though I'm not particularly worried about that as it's usually very obvious if you're talking about the type system or not lol. I'm also currently trying to write documentation about aliases and it's somewhat awkward/confusing to be talking about *weak* aliases, when I'm not really sure what the basis for that as the term actually *is*. I would also be happy to just find out there's a nice meaning behind calling them "weak" aliases :-) r? `@oli-obk` maybe we want a types MCP to decide on a specific naming here? or maybe we think its just too late to go back on this naming decision ^^'
2025-04-28Rollup merge of #140220 - GuillaumeGomez:doctest-main-wrapping, r=fmeaseGuillaume Gomez-5/+22
Fix detection of main function if there are expressions around it Fixes #140162. Fixes #139651. Once this is merged, we can backport and I'll send a follow-up to emit a warning in case a `main` function is about to be "wrapped" (and therefore not run). r? `@fmease` try-job: x86_64-mingw-1
2025-04-28Introduce `BoxMarker` to pretty-printing.Nicholas Nethercote-4/+4
The pretty-printers open and close "boxes" of text a lot. The open and close operations must be matched. The matching is currently all implicit and very easy to get wrong. (#140280 and #140246 are two recent pretty-printing fixes that both involved unclosed boxes.) This commit introduces `BoxMarker`, a marker type that represents an open box. It makes box opening/closing explicit, which makes it much easier to understand and harder to get wrong. The commit also removes many comments are on `end` calls saying things like "end outer head-block", "Close the outer-box". These demonstrate how confusing the implicit approach was, but aren't necessary any more.
2025-04-27Auto merge of #140291 - GuillaumeGomez:doctest-2024-stdout, r=notriddlebors-1/+16
Correctly display stdout and stderr in case a doctest is failing Fixes https://github.com/rust-lang/rust/issues/140289. Since the doctest is actually running itself, we need to handle the output directly inside it. cc `@fmease` r? `@notriddle`
2025-04-27Fix bad handling of macros if there is already a `main` functionGuillaume Gomez-1/+4
2025-04-25If there is a `;` alone, we consider that the doctest needs to be put inside ↵Guillaume Gomez-2/+0
a function
2025-04-25Improve codeGuillaume Gomez-4/+7
2025-04-25Correctly display stdout and stderr in case a doctest is failingGuillaume Gomez-1/+16
2025-04-25Rollup merge of #140248 - GuillaumeGomez:fix-impl-block-items-indent, ↵Matthias Krüger-12/+19
r=notriddle Fix impl block items indent Fixes #139771. Now, all impl block "before impl block items" indent are the same (ie, item info and documentation). With this fix, it looks like this: ![Screenshot From 2025-04-24 12-32-40](https://github.com/user-attachments/assets/907803a2-2949-4d01-afa5-fc3132d10ff2) You can test it [here](https://rustdoc.crud.net/imperio/fix-impl-block-items-indent/foo/struct.Context.html). r? `@notriddle`
2025-04-25Rollup merge of #137096 - ehuss:stabilize-doctest-xcompile, r=fmeaseMatthias Krüger-69/+30
Stabilize flags for doctest cross compilation This makes the following changes in preparation for supporting doctest cross-compiling in cargo: - Renames `--runtool` and `--runtool-arg` to `--test-runtool` and `--test-runtool-arg` to maintain consistency with other `--test-*` arguments. - Stabilizes the `--test-runtool` and `--test-runtool-arg`. These are needed in order to support cargo's `target.runner` option which specifies a runner to execute a cross-compiled doctest (for example, qemu). - Stabilizes the `--enable-per-target-ignores` flag by removing it and making it unconditionally enabled. This makes it possible to disable a doctest on a per-target basis, which I think will be helpful for rolling out this feature. These changes were suggested in https://rust-lang.zulipchat.com/#narrow/channel/266220-t-rustdoc/topic/stabilizing.20doctest.20xcompile/near/409281127 The intent is to stabilize the doctest-xcompile feature in cargo. This will help ensure that for projects that do cross-compile testing that their doctests are also covered. Currently there is a somewhat surprising behavior that they are ignored. Closes https://github.com/rust-lang/rust/issues/64245 try-job: x86_64-msvc-1
2025-04-24Remove `weak` alias terminologyBoxy-2/+2
2025-04-24Fix indent of impl docsGuillaume Gomez-1/+4
2025-04-24Make impl item info come before docGuillaume Gomez-11/+15
2025-04-23Fix detection of `main` function if there are expressions around itGuillaume Gomez-4/+17
2025-04-23Unify sidebar buttons to use the same imageGuillaume Gomez-21/+22
2025-04-22Auto merge of #140138 - ChrisDenton:rollup-zw7jibi, r=ChrisDentonbors-20/+20
Rollup of 5 pull requests Successful merges: - #139981 (Don't compute name of associated item if it's an RPITIT) - #140077 (Construct OutputType using macro and print [=FILENAME] help info) - #140081 (Update `libc` to 0.2.172) - #140094 (Improve diagnostics for pointer arithmetic += and -= (fixes #137391)) - #140128 (Use correct annotation for CSS pseudo elements) r? `@ghost` `@rustbot` modify labels: rollup
2025-04-22Rollup merge of #140128 - GuillaumeGomez:pseudo-elements, r=notriddleChris Denton-20/+20
Use correct annotation for CSS pseudo elements The list of CSS pseudo elements is pretty short so it was easy to go through. Even though the `:` is accepted, it's incorrect. For a description of CSS pseudo elements: https://developer.mozilla.org/en-US/docs/Web/CSS/Pseudo-elements r? ``@notriddle``
2025-04-22Auto merge of #139897 - nnethercote:rm-OpenDelim-CloseDelim, r=petrochenkovbors-2/+2
Remove `token::{Open,Close}Delim` By replacing them with `{Open,Close}{Param,Brace,Bracket,Invisible}`. PR #137902 made `ast::TokenKind` more like `lexer::TokenKind` by replacing the compound `BinOp{,Eq}(BinOpToken)` variants with fieldless variants `Plus`, `Minus`, `Star`, etc. This commit does a similar thing with delimiters. It also makes `ast::TokenKind` more similar to `parser::TokenType`. This requires a few new methods: - `TokenKind::is_{,open_,close_}delim()` replace various kinds of pattern matches. - `Delimiter::as_{open,close}_token_kind` are used to convert `Delimiter` values to `TokenKind`. Despite these additions, it's a net reduction in lines of code. This is because e.g. `token::OpenParen` is so much shorter than `token::OpenDelim(Delimiter::Parenthesis)` that many multi-line forms reduce to single line forms. And many places where the number of lines doesn't change are still easier to read, just because the names are shorter, e.g.: ``` - } else if self.token != token::CloseDelim(Delimiter::Brace) { + } else if self.token != token::CloseBrace { ``` r? `@petrochenkov`
2025-04-21Use correct annotation for CSS pseudo elementsGuillaume Gomez-20/+20
2025-04-21Rollup merge of #140052 - GuillaumeGomez:fix-140026, r=nnethercoteChris Denton-1/+6
Fix error when an intra doc link is trying to resolve an empty associated item Fixes https://github.com/rust-lang/rust/issues/140026. Assigning ```@nnethercote``` since they're the one who wrote the initial change. I updated rustdoc code instead of compiler's because I think it makes more sense that the caller ensures on their side that the name they're looking for isn't empty. r? ```@nnethercote```
2025-04-21Remove `token::{Open,Close}Delim`.Nicholas Nethercote-2/+2
By replacing them with `{Open,Close}{Param,Brace,Bracket,Invisible}`. PR #137902 made `ast::TokenKind` more like `lexer::TokenKind` by replacing the compound `BinOp{,Eq}(BinOpToken)` variants with fieldless variants `Plus`, `Minus`, `Star`, etc. This commit does a similar thing with delimiters. It also makes `ast::TokenKind` more similar to `parser::TokenType`. This requires a few new methods: - `TokenKind::is_{,open_,close_}delim()` replace various kinds of pattern matches. - `Delimiter::as_{open,close}_token_kind` are used to convert `Delimiter` values to `TokenKind`. Despite these additions, it's a net reduction in lines of code. This is because e.g. `token::OpenParen` is so much shorter than `token::OpenDelim(Delimiter::Parenthesis)` that many multi-line forms reduce to single line forms. And many places where the number of lines doesn't change are still easier to read, just because the names are shorter, e.g.: ``` - } else if self.token != token::CloseDelim(Delimiter::Brace) { + } else if self.token != token::CloseBrace { ```
2025-04-19Rollup merge of #140008 - GuillaumeGomez:cleanup-clean_maybe_renamed_item, ↵Chris Denton-14/+33
r=nnethercote Improve `clean_maybe_renamed_item` function code a bit Follow-up of #139846. This is what I tried to say in there: the `name` variable can be unwrapped in most cases so better do it directly once and for all if possible and move the cases where it's not possible above. r? `@nnethercote`
2025-04-19Fix error when an intra doc link is trying to resolve an empty associated itemGuillaume Gomez-1/+6
2025-04-18Make rustdoc JSON Span column 1-based, just like line numbersGuillaume Gomez-2/+2
2025-04-18Improve `clean_maybe_renamed_item` function code a bitGuillaume Gomez-14/+33
2025-04-18Rollup merge of #139913 - fmease:rustdoc-fix-fn-param-handling, r=GuillaumeGomezMatthias Krüger-159/+129
rustdoc/clean: Fix lowering of fn params (fixes correctness & HIR vs. middle parity regressions) **(0)** PR #136411 aimed to stop rendering unnamed params of fn ptr types as underscores in the common case (e.g., `fn(_: i32)` → `fn(i32)`) to make the rendered output stylistically more conventional. **(0.a)** However, since the cleaning fn that the PR modified is also used for lowering the HIR params of foreign fns and required assoc fns in traits, it accidentally butchered the rendering of the latter two: ```rs pub trait Trait { fn assoc_fn(_: i32); } // as well as (Rust 2015 only): fn assoc_fn(i32); unsafe extern "C" { pub fn foreign_fn(_: i32); } // Since 1.86 the fns above gets mis-rendered as: pub fn assoc_fn(: i32) // <-- BUTCHERED pub unsafe extern "C" fn foreign_fn(: i32) // <-- BUTCHERED ``` **(0.b)** Furthermore, it broke parity with middle cleaning (which includes inlined cross-crate re-exports) re-regressing parts of #44306 I once fixed in PR #103885. **(1)** Lastly, PR #139035 introduced an ICE triggered by the following input file: ```rs trait Trait { fn anon(()) {} } // internal error: entered unreachable code ``` --- This PR fixes all of these regressions and in the first commit renames several types and fns to be more ~~correct~~ descriptive and legible. ~~It also refactors `Param.name` to be of type `Option<Symbol>` instead `Symbol` (where `None` ~ `kw::Empty`), so rendering mistakes like that can no longer creep in like that (ignoring tests). CC #137978.~~ Independently done in PR #139846 a day prior.
2025-04-18Rollup merge of #139615 - nnethercote:rm-name_or_empty, r=jdonszelmannMatthias Krüger-19/+13
Remove `name_or_empty` Another step towards #137978. r? ``@jdonszelmann``
2025-04-18Rollup merge of #139393 - ↵Matthias Krüger-0/+60
willglynn:rustdoc_output_target_feature_information, r=aDotInTheVoid rustdoc-json: Output target feature information `#[target_feature]` attributes refer to a target-specific list of features. Enabling certain features can imply enabling other features. Certain features are always enabled on certain targets, since they are required by the target's ABI. Features can also be enabled indirectly based on other compiler flags. Feature information is ultimately known to `rustc`. Rather than force external tools to track it – which may be wildly impractical due to `-C target-cpu` – have `rustdoc` output `rustc`'s feature data. This change is motivated by https://github.com/obi1kenobi/cargo-semver-checks/issues/1246, which intends to detect semver hazards caused by `#[target_feature]`. try-job: aarch64-gnu try-job: armhf-gnu try-job: test-various try-job: x86_64-msvc-1 try-job: i686-msvc-1 try-job: x86_64-mingw-1 try-job: aarch64-apple
2025-04-17Rollup merge of #139943 - fmease:rustdoc-ixcre-trait-aliases, r=GuillaumeGomezMatthias Krüger-25/+27
rustdoc: Support inlined cross-crate re-exported trait aliases Previously we'd just drop them. As a result of this PR, [`core::ptr::Thin`](https://doc.rust-lang.org/nightly/core/ptr/traitalias.Thin.html) will be admitted into the `std` façade! Also, render the where clause *after* the bounds / the `=`, not before them, as it should be. r? rustdoc
2025-04-17rustdoc: Properly clean fn params in all contextsLeón Orell Valerian Liehr-35/+32
2025-04-17rustdoc/clean: Change terminology of items pertaining to (formal) fn params ↵León Orell Valerian Liehr-134/+107
from "argument" to "parameter"
2025-04-17Support inlined cross-crate re-exported trait aliasesLeón Orell Valerian Liehr-25/+27
2025-04-17Replace infallible `name_or_empty` methods with fallible `name` methods.Nicholas Nethercote-19/+13
I'm removing empty identifiers everywhere, because in practice they always mean "no identifier" rather than "empty identifier". (An empty identifier is impossible.) It's better to use `Option` to mean "no identifier" because you then can't forget about the "no identifier" possibility. Some specifics: - When testing an attribute for a single name, the commit uses the `has_name` method. - When testing an attribute for multiple names, the commit uses the new `has_any_name` method. - When using `match` on an attribute, the match arms now have `Some` on them. In the tests, we now avoid printing empty identifiers by not printing the identifier in the `error:` line at all, instead letting the carets point out the problem.
2025-04-17Rollup merge of #139846 - nnethercote:kw-Empty-rustdoc, r=GuillaumeGomezMatthias Krüger-46/+63
Remove `kw::Empty` uses in rustdoc Helps with #137978. r? ``@GuillaumeGomez``
2025-04-15rustdoc: Output target feature informationWill Glynn-0/+60
`#[target_feature]` attributes refer to a target-specific list of features. Enabling certain features can imply enabling other features. Certain features are always enabled on certain targets, since they are required by the target's ABI. Features can also be enabled indirectly based on other compiler flags. Feature information is ultimately known to `rustc`. Rather than force external tools to track it -- which may be wildly impractical due to `-C target-cpu` -- have `rustdoc` output `rustc`'s feature data.
2025-04-15Rollup merge of #138455 - yotamofek:pr/rustdoc/more-impl-display, ↵Matthias Krüger-230/+228
r=GuillaumeGomez `librustdoc`: more `impl fmt::Display` Continuation of #137425 and #136828 and #136784 Working towards getting rid of the `write_str` helper r? `@GuillaumeGomez` (if you want!)
2025-04-15Avoid using `kw::Empty` for param names in rustdoc.Nicholas Nethercote-8/+11
2025-04-15Avoid using `kw::Empty` when comparing names.Nicholas Nethercote-4/+7