| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
r=GuillaumeGomez
rustdoc: search by macro when query ends with `!`
Related to #96399
Note: the `never` type alias is tested in [`/tests/rustdoc-js-std/alias-3.js`](https://github.com/notriddle/rust/blob/08ad401633037cc226b3806a3c5f48c2f34703bf/tests/rustdoc-js-std/alias-3.js)
## Before
## After
|
|
|
|
Co-Authored-By: GuillaumeGomez <guillaume1.gomez@gmail.com>
|
|
|
|
Related to #96399
|
|
$ wc -c search-index.old.js search-index.new.js
3940530 search-index.old.js
3843222 search-index.new.js
((3940530-3843222)/3940530)*100 = 2.47%
$ wc -c search-index.old.js.gz search-index.new.js.gz
380251 search-index.old.js.gz
379434 search-index.new.js.gz
((380251-379434)/380251)*100 = 0.214%
|
|
r=GuillaumeGomez
rustdoc: merge doctest tooltip with notable traits tooltip
Fixes https://discord.com/channels/442252698964721669/443150878111694848/1066420140167680000
<details><summary>a user report where the tooltip arrow overlaps the text</summary>
</details>
Fixes #91100
Preview: <https://notriddle.com/notriddle-rustdoc-demos/simplify-doctest-tooltip/std/vec/struct.Vec.html#indexing>
Screenshot:
|
|
Improve JS function itemTypeFromName code a bit
Very small code improvement replacing a `for` loop with `findIndex` method.
r? ````@notriddle````
|
|
|
|
r=GuillaumeGomez
rustdoc: remove inconsistently-present sidebar tooltips
Discussed in https://rust-lang.zulipchat.com/#narrow/stream/266220-rustdoc/topic/Inconsistent.20sidebar.20tooltips/near/323565625
|
|
r=GuillaumeGomez
rustdoc: compute maximum Levenshtein distance based on the query
Preview: https://notriddle.com/notriddle-rustdoc-demos/search-lev-distance-2023/std/index.html?search=regex
The heuristic is pretty close to the name resolver, maxLevDistance = `Math.floor(queryLen / 3)`.
Fixes #103357
Fixes #82131
Similar to https://github.com/rust-lang/rust/pull/103710, but following the suggestion in https://github.com/rust-lang/rust/pull/103710#issuecomment-1296360267 to use `floor` instead of `ceil`, and unblocked now that https://github.com/rust-lang/rust/pull/105796 made it so that setting the max lev distance to `0` doesn't cause substring matches to be removed.
|
|
Discussed in
https://rust-lang.zulipchat.com/#narrow/stream/266220-rustdoc/topic/Inconsistent.20sidebar.20tooltips/near/323565625
|
|
|
|
Keep all theme-updating logic together
Prior to this PR, if the page is restored from the browser bfcache¹, we call `switchToSavedTheme`. But `switchToSavedTheme` never looks at the `use-system-theme` preference. Further, if it can't find a saved theme, it will fall back to the default of "light".
For a user with cookies disabled² whose preferred color scheme is dark, this means the theme will wobble back and forth between dark and light. The sequence that occurs is,
1. The page is loaded. During a page load, we consult `use-system-theme`: as cookies are disabled, this preference is unset. The default is true.
Because the default is true, we look at the preferred color scheme: for our example user, that's "dark". **The page theme is set to dark.** We'll attempt to store these preferences in localStorage, but fail due to cookies being disabled.
2. The user navigates through the docs. Subsequent page loads happen, and the same process in step 1 recurs. Previous pages are (potentially) put into the bfcache.
3. The user navigates backwards/forwards, causing a page in bfcache to be pulled out of cache. The `pageShow` event handler is triggered. However, this calls `switchToSavedTheme`: this doesn't consider the system theme, as noted above. Instead, it only looks for a saved theme. However, with cookies disabled, there is none. It defaults to light. **The page theme is set to light!** The user wonders why the dark theme is lost.
There are effectively two functions trying to determine and apply the correct theme: `updateSystemTheme` and `switchToSavedTheme`. Thus, we merge them into just one: `updateTheme`. This function contains all the logic for determining the correct theme, and is called in all circumstances where we need to set the theme:
* The initial page load
* If the browser preferred color scheme (i.e., light/dark mode) is changed
* If the page is restored from bfcache
* If the user updates the theme preferences (i.e., in `settings.js`)
Fixes https://github.com/rust-lang/rust/issues/94250.
¹bfcache: https://web.dev/bfcache/ The bfcache is used to sleep a page, if the user navigates away from it, and to restore it from cache if the user returns to it.
²Note that the browser preference that enables/disables cookies really controls many forms of storage. The same preference thus also affects localStorage. (This is so a normal browser user doesn't need to understand the distinction between "cookies" and "localStorage".)
|
|
Prior to this PR, if the page is restored from the browser bfcache¹, we
call `switchToSavedTheme`. But `switchToSavedTheme` never looks at the
`use-system-theme` preference. Further, if it can't find a saved theme,
it will fall back to the default of "light".
For a user with cookies disabled² whose preferred color scheme is dark,
this means the theme will wobble back and forth between dark and light.
The sequence that occurs is,
1. The page is loaded. During a page load, we consult
`use-system-theme`: as cookies are disabled, this preference is
unset. The default is true.
Because the default is true, we look at the preferred color scheme:
for our example user, that's "dark". **The page theme is set to
dark.** We'll attempt to store these preferences in localStorage, but
fail due to cookies being disabled.
2. The user navigates through the docs. Subsequent page loads happen,
and the same process in step 1 recurs. Previous pages are
(potentially) put into the bfcache.
3. The user navigates backwards/forwards, causing a page in bfcache to
be pulled out of cache. The `pageShow` event handler is triggered.
However, this calls `switchToSavedTheme`: this doesn't consider the
system theme, as noted above. Instead, it only looks for a saved
theme. However, with cookies disabled, there is none. It defaults to
light. **The page theme is set to light!** The user wonders why the
dark theme is lost.
There are effectively two functions trying to determine and apply the
correct theme: `updateSystemTheme` and `switchToSavedTheme`. Thus, we
merge them into just one: `updateTheme`. This function contains all the
logic for determining the correct theme, and is called in all
circumstances where we need to set the theme:
* The initial page load
* If the browser preferred color scheme (i.e., light/dark mode) is
changed
* If the page is restored from bfcache
* If the user updates the theme preferences (i.e., in `settings.js`)
Fixes #94250.
¹bfcache: https://web.dev/bfcache/ The bfcache is used to sleep a page,
if the user navigates away from it, and to restore it from cache if the
user returns to it.
²Note that the browser preference that enables/disables cookies really
controls many forms of storage. The same preference thus also affects
localStorage. (This is so a normal browser user doesn't need to
understand the distinction between "cookies" and "localStorage".)
|
|
|
|
Fixes https://discord.com/channels/442252698964721669/443150878111694848/1066420140167680000
Fixes #91100
|
|
|
|
* Changes the class names so that they all start with `setting-`.
That should make it harder to accidentally use a setting class outside
the settings popover, where loading the CSS might accidentally change
the styles of something unrelated.
* Get rid of an unnecessary wrapper DIV around the radio button line.
* Simplify CSS selectors by making the DOM easier and more intuitive
to target.
|
|
The comment says that it is called from main.js, but there don't seem to
be any references to it in main.js.
A quick ripgrep says there are no references in all of librustdoc.
|
|
The heuristic is pretty close to the name resolver.
Fixes #103357
|
|
r=GuillaumeGomez
rustdoc: fix corner cases with "?" JS keyboard command
|
|
notriddle:notriddle/rustdoc-search-stop-doing-demerits, r=GuillaumeGomez
rustdoc: simplify JS search routine by not messing with lev distance
Since the sorting function accounts for an `index` field, there's not much reason to also be applying changes to the levenshtein distance. Instead, we can just not treat `lev` as a filter if there's already a non-sentinel value for `index`.
<details>
This change gives slightly more weight to the index and path part, as search criteria, than it used to. This changes some of the test cases, but not in any obviously-"worse" way, and, in particular, substring matches are a bigger deal than levenshtein distances (we're assuming that a typo is less likely than someone just not typing the entire name).
The biggest change is the addition of a `path_lev` field to result items. It's always zero if the search query has no parent path part and for type queries, making the check in the `sortResults` function a no-op. When it's present, it is used to implement different precedence for the parent path and the tail.
Consider the query `hashset::insert`, a test case [that already exists and can be found here](https://github.com/rust-lang/rust/blob/5c6a1681a9a7b815febdd9de2f840da338984e68/src/test/rustdoc-js-std/path-ordering.js). We want the ordering shown in the test case:
```
{ 'path': 'std::collections::hash_set::HashSet', 'name': 'insert' },
{ 'path': 'std::collections::hash_set::HashSet', 'name': 'get_or_insert' },
{ 'path': 'std::collections::hash_set::HashSet', 'name': 'get_or_insert_with' },
{ 'path': 'std::collections::hash_set::HashSet', 'name': 'get_or_insert_owned' },
{ 'path': 'std::collections::hash_map::HashMap', 'name': 'insert' },
```
We do not want this ordering, which is the ordering that would occur if substring position took priority over `path_lev`:
```
{ 'path': 'std::collections::hash_set::HashSet', 'name': 'insert' },
{ 'path': 'std::collections::hash_map::HashMap', 'name': 'insert' }, // BAD
{ 'path': 'std::collections::hash_set::HashSet', 'name': 'get_or_insert' },
{ 'path': 'std::collections::hash_set::HashSet', 'name': 'get_or_insert_with' },
{ 'path': 'std::collections::hash_set::HashSet', 'name': 'get_or_insert_owned' },
```
We also do not want `HashSet::iter` to appear before `HashMap::insert`, which is what would happen if `path_lev` took priority over the appearance of any substring match. This is why the `sortResults` function has `path_lev` sandwiched between a `index < 0` check and a `index` comparison check:
```
{ 'path': 'std::collections::hash_set::HashSet', 'name': 'insert' },
{ 'path': 'std::collections::hash_set::HashSet', 'name': 'get_or_insert' },
{ 'path': 'std::collections::hash_set::HashSet', 'name': 'get_or_insert_with' },
{ 'path': 'std::collections::hash_set::HashSet', 'name': 'get_or_insert_owned' },
{ 'path': 'std::collections::hash_set::HashSet', 'name': 'iter' }, // BAD
{ 'path': 'std::collections::hash_map::HashMap', 'name': 'insert' },
```
The old code implemented a similar feature by manipulating the `lev` member based on whether a substring match was found and averaging in the path distance (`item.lev = name_lev + path_lev / 10`), so the path lev wound up acting like a tie breaker, but it gives slightly different results for `Vec::new`, [changing the test case](https://github.com/rust-lang/rust/pull/105796/files#diff-b346e2ef72a407915f438063c8c2c04f7a621df98923d441b41c0312211a5b21) because of the slight changes to ordering priority.
</details>
Based on https://github.com/rust-lang/rust/pull/103710#issuecomment-1296894296
Previews:
* https://notriddle.com/notriddle-rustdoc-demos/rustdoc-search-stop-doing-demerits/std/index.html
* https://notriddle.com/notriddle-rustdoc-demos/rustdoc-search-stop-doing-demerits-compiler/index.html
|
|
This extends the special case with checkbox settings to also cover radios.
|
|
This prevents some strange blur-event-related bugs with the "?" command
by ensuring that the focus remains in the same spot when the settings
area closes.
|
|
rustdoc: remove deprecated / unused code from main.js
|
|
|
|
|
|
|
|
Since the sorting function accounts for an `index` field, there's not much
reason to also be applying changes to the levenshtein distance. Instead,
we can just not treat `lev` as a filter if there's already a non-sentinel
value for `index`.
This change gives slightly more weight to the index and path part, as
search criteria, than it used to. This changes some of the test cases,
but not in any obviously-"worse" way, and, in particular, substring matches
are a bigger deal than levenshtein distances (we're assuming that a typo
is less likely than someone just not typing the entire name).
Based on
https://github.com/rust-lang/rust/pull/103710#issuecomment-1296894296
|
|
r=GuillaumeGomez
rustdoc: remove `docblock` class from notable trait popover
This commit builds on b72de9be74dd5ac1d8b23d5ece03a7690274a14c, which removes the `docblock` class from the All Items page, and 9457380ac902db3febf92077c5b645db55998ad4, which removes the `docblock` class from the item decl.
Fixes #92974
|
|
rustdoc: remove unnecessary DOM class `h1.fqn`
It's misleading. The main heading sometimes isn't an fully qualified name at all.
It's also redundant. It's always a child of `div.main-heading`, so just use that.
|
|
This commit builds on b72de9be74dd5ac1d8b23d5ece03a7690274a14c, which removes
the `docblock` class from the All Items page, and
9457380ac902db3febf92077c5b645db55998ad4, which removes the `docblock` class
from the item decl.
Fixes #92974
|
|
This swaps things around so that the class that gets used more often has
the shorter name.
|
|
It's misleading. The main heading sometimes isn't an fully qualified name at all.
It's also redundant. It's always a child of `div.main-heading`, so just use that.
|
|
rustdoc: fix buggy JS check for absolute URL
The old code did the wrong thing when faced with a crate named "http".
|
|
The old code did the wrong thing when faced with a crate named "http".
|
|
No need to prevent default click behavior on a <div>, it will also disable all child click behavior.
|
|
This renames the ID, which is only used in search results, to
`#search-tabs`. Also changes the `.count` to a span, so it doesn't need its
display mode to be overridden.
|
|
|
|
The old name doesn't get across where it's really supposed to be used.
|
|
MDN directly recommends this in <https://developer.mozilla.org/en-US/docs/Web/HTML/Element/link>,
since "CSS is the only stylesheet language used on the web."
Like 07a243b2a46384235d7e2c08688978b7cf018973, but a few places that were
missed the first time.
|
|
|
|
|
|
|
|
* Examples take up less screen height.
* Snippets from binary crates are prioritized.
* toggle-all-docs does not expand "More examples" sections.
|
|
Fix UI issues with Rustdoc scrape-examples feature.
A few regressions have been introduced into scrape-examples in the last few months. This commit fixes those regressions:
* Help file was being loaded from the wrong place (introduced in f9e1f6ffdf03ec33cb29e20c88fc7bcc938c7f42).
* CSS selector in JS has a typo (introduced in 14897180ae6a0506a5ad0a9f6a30ae1f75916179).
* Line numbers in scraped example code snippets are overflowing (not sure if this was ever fixed). Changing from flexbox to grid display fixed this issue.
|
|
|
