about summary refs log tree commit diff
path: root/src/doc/rustdoc
AgeCommit message (Collapse)AuthorLines
2024-04-24chore: fix some typos in commentswhosehang-2/+2
Signed-off-by: whosehang <whosehang@outlook.com>
2024-04-15Move --check-cfg documentation to stable booksUrgau-16/+14
2024-04-04rustdoc prioritise cargo doc: suggestions appliedHarry Han-1/+10
2024-03-15doc: add --test-builder/--test-builder-wrapperTravis Finkenauer-0/+29
2024-03-11rustdoc-search: add search query syntax `Fn(T) -> U`Michael Howell-16/+30
This is implemented, in addition to the ML-style one, because Rust does it. If we don't, we'll never hear the end of it. This commit also refactors some duplicate parts of the parser into a dedicated function.
2024-03-11rustdoc-search: parse and search with ML-style HOFMichael Howell-3/+5
Option::map, for example, looks like this: option<t>, (t -> u) -> option<u> This syntax searches all of the HOFs in Rust: traits Fn, FnOnce, and FnMut, and bare fn primitives.
2024-02-23remove repetitive wordscui fliter-1/+1
Signed-off-by: cui fliter <imcusg@gmail.com>
2024-02-13Rollup merge of #121021 - GuillaumeGomez:extend-intra-doc-link-chapter, ↵Matthias Krüger-0/+18
r=notriddle Extend intra-doc link chapter in the rustdoc book Linked to #117178. r? `@notriddle`
2024-02-13Extend intra-doc link chapter in the rustdoc bookGuillaume Gomez-0/+18
2024-02-01Extend "Attributes" section in the `re-exports` pageGuillaume Gomez-0/+29
2023-12-26Add a few more docsMichael Howell-34/+14
2023-12-26rustdoc: search for tuples and unit by type with `()`Michael Howell-11/+56
2023-12-23Rollup merge of #119245 - GuillaumeGomez:improve-docs, r=fmeaseMatthias Krüger-0/+16
Improve documentation for using warning blocks in documentation From [this comment](https://github.com/rust-lang/rust/issues/79710#issuecomment-1868225357), I think markdown can be surprising sometimes so better explain a bit better how to use it correctly. r? `@notriddle`
2023-12-23Improve documentation for using warning blocks in documentationGuillaume Gomez-0/+16
2023-12-22fix missed typoTakashi Idobe-1/+1
2023-12-22fix some typos found scrolling through the docsTakashi Idobe-2/+2
2023-12-12Change a typo mistake in the-doc-attribute.md Hosssein-1/+1
I guess that `Bar` in the section I changed should be `bar` because when I run the program it has its page under struct but bar doesn't have any page.
2023-11-19rustdoc: update book with info on type bindingsMichael Howell-4/+43
2023-10-21fix what-to-include doc exampleCameron Ditchfield-1/+1
Fixes the second example in the Examples section of what-to-include.md by marking main as a function.
2023-10-21fix broken link to ayu theme in the rustdoc bookRyan Mehri-1/+1
2023-10-17Rollup merge of #111072 - Urgau:check-cfg-new-syntax, r=petrochenkovMatthias Krüger-2/+2
Add new simpler and more explicit syntax for check-cfg <details> <summary> Old proposition (before the MCP) </summary> This PR adds a new simpler and more explicit syntax for check-cfg. It consist of two new form: - `exhaustive(names, values)` - `configure(name, "value1", "value2", ... "valueN")` The preview forms `names(...)` and `values(...)` have implicit meaning that are not strait-forward. In particular `values(foo)`&`values(bar)` and `names(foo, bar)` are not equivalent which has created [some confusions](https://github.com/rust-lang/rust/pull/98080). Also the `names()` and `values()` form are not clear either and again created some confusions where peoples believed that `values()`&`values(foo)` could be reduced to just `values(foo)`. To fix that the two new forms are made to be explicit and simpler. See the table of correspondence: - `names()` -> `exhaustive(names)` - `values()` -> `exhaustive(values)` - `names(foo)` -> `exhaustive(names)`&`configure(foo)` - `values(foo)` -> `configure(foo)` - `values(feat, "foo", "bar")` -> `configure(feat, "foo", "bar")` - `values(foo)`&`values(bar)` -> `configure(foo, bar)` - `names()`&`values()`&`values(my_cfg)` -> `exhaustive(names, values)`&`configure(my_cfg)` Another benefits of the new syntax is that it allow for further options (like conditional checking for --cfg, currently always on) without syntax change. The two previous forms are deprecated and will be removed once cargo and beta rustc have the necessary support. </details> This PR is the first part of the implementation of [MCP636 - Simplify and improve explicitness of the check-cfg syntax](https://github.com/rust-lang/compiler-team/issues/636). ## New `cfg` form It introduces the new [`cfg` form](https://github.com/rust-lang/compiler-team/issues/636) and deprecate the other two: ``` rustc --check-cfg 'cfg(name1, ..., nameN, values("value1", "value2", ... "valueN"))' ``` ## Default built-in names and values It also changes the default for the built-in names and values checking. - Built-in values checking would always be activated as long as a `--check-cfg` argument is present - Built-in names checking would always be activated as long as a `--check-cfg` argument is present **unless** if any `cfg(any())` arg is passed ~~**Note: depends on https://github.com/rust-lang/rust/pull/111068 but is reviewable (last two commits)!**~~ Resolve https://github.com/rust-lang/compiler-team/issues/636 r? `@petrochenkov`
2023-10-14Rollup merge of #115439 - fmease:rustdoc-priv-repr-transparent-heuristic, ↵Matthias Krüger-0/+20
r=GuillaumeGomez rustdoc: hide `#[repr(transparent)]` if it isn't part of the public ABI Fixes #90435. This hides `#[repr(transparent)]` when the non-1-ZST field the struct is "transparent" over is private. CC `@RalfJung` Tentatively nominating it for the release notes, feel free to remove the nomination. `@rustbot` label needs-fcp relnotes A-rustdoc-ui
2023-10-13MCP636: Add simpler and more explicit syntax to check-cfgUrgau-2/+2
This add a new form and deprecated the other ones: - cfg(name1, ..., nameN, values("value1", "value2", ... "valueN")) - cfg(name1, ..., nameN) or cfg(name1, ..., nameN, values()) - cfg(any()) It also changes the default exhaustiveness to be enable-by-default in the presence of any --check-cfg arguments.
2023-10-08rustdoc: remove rust logo from non-Rust cratesMichael Howell-0/+15
2023-09-25Fix typo in rustdoc unstable features docDaniPopes-1/+1
2023-09-19Rollup merge of #112725 - notriddle:notriddle/advanced-search, r=GuillaumeGomezGuillaume Gomez-50/+243
rustdoc-search: add support for type parameters r? `@GuillaumeGomez` ## Preview * https://notriddle.com/rustdoc-html-demo-4/advanced-search/rustdoc/read-documentation/search.html * https://notriddle.com/rustdoc-html-demo-4/advanced-search/std/index.html?search=option%3Coption%3CT%3E%3E%20-%3E%20option%3CT%3E * https://notriddle.com/rustdoc-html-demo-4/advanced-search/std/index.html?search=option%3CT%3E,%20E%20-%3E%20result%3CT,%20E%3E * https://notriddle.com/rustdoc-html-demo-4/advanced-search/std/index.html?search=-%3E%20option%3CT%3E ## Description When writing a type-driven search query in rustdoc, specifically one with more than one query element, non-existent types become generic parameters instead of auto-correcting (which is currently only done for single-element queries) or giving no result. You can also force a generic type parameter by writing `generic:T` (and can force it to not use a generic type parameter with something like `struct:T` or whatever, though if this happens it means the thing you're looking for doesn't exist and will give you no results). There is no syntax provided for specifying type constraints for generic type parameters. When you have a generic type parameter in a search query, it will only match up with generic type parameters in the actual function, not concrete types that match, not concrete types that implement a trait. It also strictly matches based on when they're the same or different, so `option<T>, option<U> -> option<U>` matches `Option::and`, but not `Option::or`. Similarly, `option<T>, option<T> -> option<T>` matches `Option::or`, but not `Option::and`. ## Motivation This feature is motivated by the many "combinitor"-type functions found in generic libraries, such as Option, Future, Iterator, and Entry. These highly-generic functions have names that are almost completely arbitrary, and a type signature that tells you what it actually does. This PR is a major step towards[^closure] being able to easily search for generic functions by their type signature instead of by name. Some examples of combinators that can be found using this PR (try them out in the preview): * `option<option<T>> -> option<T>` returns Option::flatten * `option<T> -> result<T>` returns Option::ok_or * `option<result<T>> -> result<option<T>>` returns Option::transpose * `entry<K, V>, FnOnce -> V` returns `Entry::or_insert_with` (and `or_insert_with_key`, since there's no way to specify the generics on FnOnce) [^closure]: For this feature to be as useful as it ought to be, you should be able to search for *trait-associated types* and *closures*. This PR does not implement either of these: they are **Future possibilities**. Trait-associated types would allow queries like `option<T> -> iterator<item=T>` to return `Option::iter`. We should also allow `option<T> -> iterator<T>` to match the associated type version. Closures would make a good way to query for things like `Option::map`. Closure support needs associated types to be represented in the search index, since `FnOnce() -> i32` desugars to `FnOnce<Output=i32, ()>`, so associated trait types should be implemented first. Also, we'd want to expose an easy way to query closures without specifying which of the three traits you want.
2023-09-18rustdoc: hide repr(transparent) if it isn't part of the public ABILeón Orell Valerian Liehr-0/+20
2023-09-15Update documentation for `custom_code_classes_in_docs` featureGuillaume Gomez-2/+6
2023-09-15Add support for double quotes in markdown codeblock attributesGuillaume Gomez-0/+11
2023-09-15Add documentation for `custom_code_classes_in_docs` featureGuillaume Gomez-0/+29
2023-09-10Fixed typo in re-exports.mdPhilVoel-1/+1
own't -> won't
2023-09-09rustdoc-doc: add `next_chunk` to list of `vec::intoiter<T> -> [T]`Michael Howell-1/+1
This didn't show up before, because of some unification bugs that were fixed in 269cb579479ab950e85a2e4078810501c29d7465
2023-09-03Update docs since path-based type search works nowMichael Howell-3/+3
2023-09-03rustdoc: write detailed chapter on search engineMichael Howell-50/+243
2023-08-28rustdoc: start new "Sections" section in the book with Aliased TypeUrgau-0/+16
2023-08-21Auto merge of #106561 - GuillaumeGomez:warning-block, r=rustdocbors-0/+13
Add warning block support in rustdoc Fixes https://github.com/rust-lang/rust/issues/79710. You can test it [here](https://rustdoc.crud.net/imperio/warning-block/foo/struct.Foo.html). It currently looks like this: ![image](https://user-images.githubusercontent.com/3050060/211413494-e1cf04e4-c081-4a9d-97db-27329405cfa7.png) So a few things to note: * Since it's a new add and it's changing the UI, we'll need to go through an FCP. * Does the UI looks good? * Is the way picked to add a warning block ok for everyone? The discussion on the issue seemed to be in favour of this solution but it doesn't hurt to double-check. cc `@rust-lang/rustdoc`
2023-08-18Fix resolution cachingKyle Lin-7/+19
2023-08-18Add warn level lint `redundant_explicit_links`Kyle Lin-0/+22
- Currently it will panic due to the resolution's caching issue
2023-08-14Add GUI test for warning blocksGuillaume Gomez-1/+2
2023-08-14Add documentation for warning blocks in rustdoc bookGuillaume Gomez-0/+12
2023-08-03Add `internal_features` lintNilstrieb-0/+1
It lints against features that are inteded to be internal to the compiler and standard library. Implements MCP #596. We allow `internal_features` in the standard library and compiler as those use many features and this _is_ the standard library from the "internal to the compiler and standard library" after all. Marking some features as internal wasn't exactly the most scientific approach, I just marked some mostly obvious features. While there is a categorization in the macro, it's not very well upheld (should probably be fixed in another PR). We always pass `-Ainternal_features` in the testsuite About 400 UI tests and several other tests use internal features. Instead of throwing the attribute on each one, just always allow them. There's nothing wrong with testing internal features^^
2023-07-17Rollup merge of #112741 - geometryolife:fix, r=workingjubileeMatthias Krüger-1/+1
fix typo in `rustdoc/src/what-is-rustdoc.md`
2023-07-02Auto merge of #108537 - ↵bors-0/+5
GuillaumeGomez:rustdoc-search-whitespace-as-separator, r=notriddle rustdoc: Allow whitespace as path separator like double colon Fixes https://github.com/rust-lang/rust/issues/108447. I think it makes sense since it allows more common cases, however it also makes the syntax heavier. Not sure what the rest of the team thinks about it. In any case we'll need to go through FCP. Full explanation for the changes is available [here](https://github.com/rust-lang/rust/pull/108537#issuecomment-1589480564). r? `@notriddle`
2023-07-01Document tracking issue for rustdoc `show-type-layout`Trevor Gross-0/+2
2023-06-17fix typo in `rustdoc/src/what-is-rustdoc.md`Joe Chen-1/+1
2023-06-15Rollup merge of #112304 - GuillaumeGomez:re-exports, r=notriddleMatthias Krüger-1/+180
Add chapter in rustdoc book for re-exports and add a regression test for `#[doc(hidden)]` behaviour Fixes https://github.com/rust-lang/rust/issues/109449. Fixes https://github.com/rust-lang/rust/issues/53417. After the discussion in #109697, I made a few PRs to fix a few corner cases: * https://github.com/rust-lang/rust/pull/112178 * https://github.com/rust-lang/rust/pull/112108 * https://github.com/rust-lang/rust/pull/111997 With this I think I covered all cases. Only thing missing at this point was a chapter covering re-exports in the rustdoc book. r? `@notriddle`
2023-06-14Add documentation for paths in rustdoc searchGuillaume Gomez-0/+5
2023-06-10rustdoc: update book with `[]` syntaxMichael Howell-0/+5
2023-06-05Add chapter for re-exports in the rustdoc bookGuillaume Gomez-1/+180
2023-05-25rustdoc book: document single tilde strikethroughLukas Markeffsky-3/+3
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-23 23:12:55 +0000