summary refs log tree commit diff
path: root/src/librustdoc/html/static
AgeCommit message (Collapse)AuthorLines
2023-09-20rustdoc: add comment about numeric spacingMichael Howell-0/+4
2023-09-19rustdoc: add test cases, and fix, search tabsMichael Howell-6/+15
2023-09-19Rollup merge of #112725 - notriddle:notriddle/advanced-search, r=GuillaumeGomezGuillaume Gomez-292/+496
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-18Move mobile topbar title creation entirely into JSGuillaume Gomez-3/+5
2023-09-15rustdoc: avoid calling `document.write` after the page loadsMichael Howell-2/+12
2023-09-15rustdoc: merge theme css into rustdoc.cssMichael Howell-396/+638
Based on https://github.com/rust-lang/rust/pull/115812#issuecomment-1717960119 Having them in separate files used to make more sense, before the migration to CSS variables made the theme files as small as they are nowadays. This is already how docs.rs and mdBook do it.
2023-09-13Merge settings.css into rustdoc.cssGuillaume Gomez-71/+64
2023-09-09rustdoc-search: fix bugs when unboxing and reordering combineMichael Howell-235/+275
2023-09-08Change syntax for anonymous functions setGuillaume Gomez-18/+18
2023-09-03rustdoc: fix test case for generics that look like namesMichael Howell-1/+2
2023-09-03rustdoc: bug fix for `-> option<t>`Michael Howell-1/+5
2023-09-03rustdoc-search: add support for type parametersMichael Howell-173/+332
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`.
2023-09-03rustdoc-search: `null`, not `-1`, for missing idMichael Howell-14/+14
This allows us to use negative numbers for others purposes.
2023-09-03Rollup merge of #115490 - pitaj:rustdoc-searchjs-comment, r=GuillaumeGomezGuillaume Gomez-8/+17
rustdoc: update comment in search.js for #107629 Addressing https://github.com/rust-lang/rust/pull/107629#issuecomment-1693460106 r? `@jsha`
2023-09-02rustdoc: update comment in search.js for #107629Peter Jaszkowiak-8/+17
2023-09-01[rustdoc] Fix path in type-based searchGuillaume Gomez-23/+89
2023-08-31Improve `search.js` codeGuillaume Gomez-17/+13
2023-08-27Unify CSS color formats a bit moreGuillaume Gomez-14/+14
2023-08-24Auto merge of #115078 - camelid:tydef-to-alias, r=aDotInTheVoid,GuillaumeGomezbors-1/+1
rustdoc: Rename typedef to type alias This matches the name used by the [Rust Reference][1], which is also what people usually call these items. [1]: https://doc.rust-lang.org/reference/items/type-aliases.html r? `@GuillaumeGomez`
2023-08-21rustdoc: Rename "Type Definition" to "Type Alias"Noah Lev-1/+1
This matches the name used by the Rust Reference [1], which is also what people usually call these items. [1]: https://doc.rust-lang.org/reference/items/type-aliases.html
2023-08-14Add warning block support in rustdocGuillaume Gomez-3/+26
2023-08-04Use similar color scheme to make it obvious they are linkedGuillaume Gomez-2/+2
2023-07-20Remove adjustments that used to be necessary for search's crate selector ↵Frank Steffahn-9/+0
appearance (padding) to look identical on Firefox. New versions of Firefox appear to have changed behavior to agree with Chrome.
2023-07-18Fix display of aliases in rustdoc search resultsGuillaume Gomez-19/+15
2023-07-14rustdoc: rename to `src-script.js`Michael Howell-0/+0
This is a separate commit to keep Git happy.
2023-07-14rustdoc: use `src` consistently over `source` in JavaScriptMichael Howell-14/+14
Since the directory that contains source files is called `src`, it makes sense to name the scripts that way, too.
2023-07-14rustdoc: use `src` consistently over `source` in codeMichael Howell-45/+45
The CSS uses an inconsistent mix of both. This commit switches it to always use `src`.
2023-07-03Rollup merge of #113285 - GuillaumeGomez:display-long-inline-cfg, r=notriddleGuillaume Gomez-3/+3
[rustdoc] Fix display of long inline cfg labels Fixes #87957. Fixes #112880. Before: ![Screenshot from 2023-07-03 13-25-47](https://github.com/rust-lang/rust/assets/3050060/401e2c6b-2cfd-4ae3-9d15-b5e1dfec4201) After: ![Screenshot from 2023-07-03 13-24-49](https://github.com/rust-lang/rust/assets/3050060/e42a34a8-bf60-409d-8a0c-1669d09e7e1e) r? `@notriddle`
2023-07-03Fix display of long inline cfg labelsGuillaume Gomez-3/+3
2023-07-02Auto merge of #108537 - ↵bors-73/+174
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-06-29Rollup merge of #113100 - GuillaumeGomez:search-result-long-name, r=notriddleTakayuki Maeda-9/+29
Fix display of long items in search results Fixes https://github.com/rust-lang/rust/issues/113060. You can test the result [here](https://rustdoc.crud.net/imperio/search-result-long-name/lib2/index.html). To make it a bit better, I also reduced a bit the size of the short documentation from half to 2 fifth of the width. r? `@notriddle`
2023-06-28Fix display of long items in search resultsGuillaume Gomez-9/+29
2023-06-27Replace `id` attribute with `name` for `<meta>` tagGuillaume Gomez-3/+3
2023-06-25Rollup merge of #112937 - camelid:align-typenames, r=notriddle,GuillaumeGomezMatthias Krüger-2/+4
rustdoc: Align search results horizontally for easy scanning The recent PR #110688 added info about an item's kind before its name in search results. However, because the kind and name are inline with no alignment, it's now hard to visually scan downward through the search results, looking at item names. This PR fixes that by horizontally aligning search results such that there are now two columns of information. r? `@GuillaumeGomez`
2023-06-23Reduce typename width to 6.25remNoah Lev-1/+1
This makes "existential type" look slightly cramped (though still readable), but it makes all other typenames look better. Existential types are currently very rare, and we can always tweak this later if necessary.
2023-06-23Make typenames a bit wider to support "existential type"Noah Lev-1/+1
2023-06-23Abbreviate long typenames so they don't get wrapped in resultsNoah Lev-2/+2
2023-06-23Link to the corresponding channel in the help popoverGuillaume Gomez-5/+6
2023-06-23Add link to rustdoc book search chapter in help popoverGuillaume Gomez-0/+3
2023-06-22Align search results horizontally for easy scanningNoah Lev-0/+2
The recent PR #110688 added info about an item's kind before its name in search results. However, because the kind and name are inline with no alignment, it's now hard to visually scan downward through the search results, looking at item names. This PR fixes that by horizontally aligning search results such that there are now two columns of information.
2023-06-19rustdoc: js: change color and reduce size of typename in search resultAlexis (Poliorcetics) Bourget-1/+7
2023-06-17Rollup merge of #112707 - GuillaumeGomez:back-in-history-fix, r=notriddleMatthias Krüger-19/+35
[rustdoc] Fix invalid handling of "going back in history" when "go to only search result" setting is enabled You can test the fix [here](https://rustdoc.crud.net/imperio/back-in-history-fix/lib2/index.html). Enable "Directly go to item in search if there is only one result", then search for `HasALongTraitWithParams` and finally go back to previous page. It should be back on the `index.html` page. The reason for this bug is that the JS state is cached as is, so when we go back to the page, it resumes where it was left, somewhat (very weird), meaning the search is run again etc. The best way to handle this is to force the JS re-execution in this case so that it doesn't try to resume from where it left and then lead us back to the current page. r? ``@notriddle``
2023-06-16Fix invalid handling of "going back in history" when "Directly go to item in ↵Guillaume Gomez-4/+21
search if there is only one result" setting is set to true
2023-06-16Auto merge of #110688 - GuillaumeGomez:result-search-type, r=notriddle,jshabors-11/+36
rustdoc: Add search result item types after their name Here what it looks like: ![Screenshot from 2023-04-22 15-16-58](https://user-images.githubusercontent.com/3050060/233789566-b5f3f625-3b78-4c56-a7ee-0a4f2d62e667.png) The idea is to improve accessibility by providing this information directly in the text and not only in the text color. Currently we already use it for doc aliases and for primitive types, so I extended it to all types. r? `@notriddle`
2023-06-16Unify history interactions in searchGuillaume Gomez-15/+14
2023-06-15Auto merge of #112233 - notriddle:notriddle/search-unify, r=GuillaumeGomezbors-166/+163
rustdoc-search: clean up type unification and "unboxing" This PR redesigns parameter matching, return matching, and generics matching to use a single function that compares two lists of types. It also makes the algorithms more consistent, so the "unboxing" behavior where `Vec<i32>` is considered a match for `i32` works inside generics, and not just at the top level.
2023-06-14Fix eBNF and handling of whitespace characters when not in a pathGuillaume Gomez-2/+11
2023-06-14Correctly display whitespace characters in search errorGuillaume Gomez-1/+1
2023-06-14Use whitespace as path separator like double colonGuillaume Gomez-71/+163
2023-06-12rustdoc-search: search never type with `!`Michael Howell-5/+43
This feature extends rustdoc to support the syntax that most users will naturally attempt to use to search for diverging functions. Part of #60485 It's already possible to do this search with `primitive:never`, but that's not what the Rust language itself uses, so nobody will try it if they aren't told or helped along.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-03 13:34:38 +0000