There are more possible optimizations left (cached length in loops) as
well as some possible bugs (shadowed variables) to fix. This is mostly
syntactic.
Rustdoc fixes for associated items
This is related to isssue #22442 and solves it partly.
This solves the search index links of associated types and constants,
so that they link to the trait page.
Also add an Associated Constants section if constants are present.
To separate concerns, instead of checking the state of `#toggle-all-docs` by looking at its label text, I add or remove a class `will-expand` depending on whether the button’s next click will expand everything. (The `if` statement’s two branches were swapped as part of this change.)
I moved the desired text values to a function `labelForToggleButton`, so changing the values will be easier. I also note in a comment the other file where the text is duplicated.
To allow the labels of both types of toggle buttons to be uniformly set, I added a `span.inner` to the global button too.
I split the template in `render.rs` into multiple lines to make room for the `span`, and that adds whitespace around the `[` and `]` text elements. That seems to be okay, though – the page still looks the same.
I updated the CSS styling for `.collapse-toggle > .inner` to add a little extra space around the symbol, to make minus signs easier to identify. (`#toggle-all-docs > .inner` does not need the same style, since its text size is bigger, so it naturally puts more space around the symbol.)
So that if people accidentally delete the character, they won’t re-type it as a hyphen, which would cause bugs.
I changed ‘+’ too, even though it won’t be re-typed incorrectly, so that it is easier to see when plus is used as a symbol for the button, and when it is used as an operator in code. It also makes it clearer that the use of an entity for minus is on purpose, so people won’t be tempted to replace the entity incorrectly with a hyphen character.
This adds search by type (for functions/methods) support to Rustdoc. Target issue is at https://github.com/rust-lang/rfcs/issues/658.
I've described my approach here: https://github.com/rust-lang/rfcs/issues/658#issuecomment-76484200. I'll copy the text in here as well:
---
Hi, it took me longer than I wished, but I have implemented this in a not-too-complex way that I think can be extended to support more complex features (like the ones mentioned [here](https://github.com/rust-lang/rust/issues/12866#issuecomment-66945317)).
The idea is to generate a JSON representation of the types of methods/functions in the existing index, and then make the JS understand when it should look by type (and not by name).
I tried to come up with a JSON representation that can be extended to support generics, bounds, ref/mut annotations and so on. Here are a few samples:
Function:
```rust
fn to_uppercase(c: char) -> char
```
```json
{
"inputs": [
{"name": "char"}
],
"output": {
"name": "char",
}
}
```
Method (implemented or defined in trait):
```rust
// in struct Vec
// self is considered an argument as well
fn capacity(&self) -> usize
```
```json
{
"inputs": [
{"name": "vec"}
],
"output": {
"name": "usize"
}
}
```
This simple format can be extended by adding more fields, like `generic: bool`, a `bounds` mapping and so on.
I have a working implementation in https://github.com/rust-lang/rust/compare/master...mihneadb:rustdoc-search-by-type. You can check out a live demo [here](http://data.mihneadb.net/doc/std/index.html?search=charext%20-%3E%20char).
The feature list is not that long:
- search by types (you *can* use generics as well, as long as you use the exact name - e.g. [`vec,t -> `](http://data.mihneadb.net/doc/std/index.html?search=vec%2C%20t%20-%3E))
- order of arguments does not matter
- `self` is took into account as well (e.g. search for `vec -> usize`)
- does not use "complex" annotations (e.g. you don't search for `&char -> char` but for `char -> char`)
My goal is to get a working, minimal "base" merged so that others can build upon it. How should I proceed? Do I open a PR (badly in need of code review since this is my first non "hello world"-ish rust code)?
---
It had been a source of huge bloat in rustdoc outputs. Of course,
we can simply disable compiler docs (as `rustc` generates over 90M
of HTML) but this approach fares better even after such decision.
Each directory now has `sidebar-items.js`, which immediately calls
`initSidebarItems` with a JSON sidebar data. This file is shared
throughout every item in the sidebar. The current item is
highlighted via a separate JS snippet (`window.sidebarCurrent`).
The JS file is designed to be loaded asynchronously, as the sidebar
is rendered before the content and slow sidebar loading blocks
the entire rendering. For the minimal accessibility without JS,
links to the parent items are left in HTML.
In the future, it might also be possible to integrate crates data
with the same fashion: `sidebar-items.js` at the root path will do
that. (Currently rustdoc skips writing JS in that case.)
This has a huge impact on the size of rustdoc outputs. Originally
it was 326MB uncompressed (37.7MB gzipped, 6.1MB xz compressed);
it is 169MB uncompressed (11.9MB gzipped, 5.9MB xz compressed) now.
The sidebar JS only takes 10MB uncompressed & 0.3MB gzipped.
This pull request add tooltips to most links of sidebar.
The tooltips display "summary line" of items' document.
Some lengthy/annoying raw markdown code are eliminated, such as links and headers.
- `[Rust](http://rust-lang.org)` displays as `Rust` (no URLs)
- `# header` displays as `header` (no `#`s)
Some inline spans, e.g. ``` `code` ``` and ```*emphasis*```, are kept as they are, for better readable.
I've make sure `&` `'` `"` `<` and `>` are properly displayed in tooltips, for example, `&'a Option<T>`.
Online preview: http://liigo.com/tmp/tooltips/std/index.html
@alexcrichton @steveklabnik since you have reviewed my previous ([v1](https://github.com/rust-lang/rust/pull/13014),[v2](https://github.com/rust-lang/rust/pull/16448)) PRs of this serise, which have been closed for technical reasons. Thank you.
Increases the delay of the search box to 500ms after key up. I tried
adding a three character minimum for setting the delay, but didn't find
it very useful.
Should close#20095
This series of commits deals with broken links to the source code. It also refactors some repetitive codes from Rustdoc. The most important commit, 1cb1f00d40, describes the rationale; this will fix a half of #16289. Other commits are reasonably independent to each other and can be made into indiviudal PRs at the request.
### Notes on the broken source links
As of bda97e8557 (I've used this to check the PR works as intended), there are 281 (!) such broken links. They can be further classified as follows:
* 178 links to incorrect item types. This is the first half of #16289, and this PR fixes all of them.
* 89 links to redirect pages. They are not technically "broken" but still doesn't give a source code. I have a fix for this in mind, which would make a redirect page slightly *fat*.
* 14 links to incorrect `DefId` in the `gotosrc` parameter. This is #15309, and affects many `liballoc` reexports in `libstd` but *nothing else* (curiously). I'm yet to track this down; might be a metadata bug (not sure).
* 0 links to the crate reexported as a different name. This is the second half of #16289, and seems not hard to fix but I'm running out of time.
Prevalence of this kind of bugs calls for a full link verifier integrated into the testing process. :S
They are just (unsafe) functions and static items to most users
and even compilers! The metadata doesn't distinguish them, so Rustdoc
ended up producing broken links (generated `ffi.*.html`, links to
`fn.*.html`). It would be best to avoid this pitfall at all.
Sometimes (e.g. on Rust CI) the "expand description" text of the
collapse toggle was displayed by default, when a page is first
loaded (even though the description is expanded), because some
Content-Security-Policy settings disable inline CSS.
Setting it the style with the `.css` method allows the output to be used
in more places.
Sometimes (e.g. on Rust CI) the "expand description" text of the
collapse toggle was displayed by default, when a page is first
loaded (even though the description is expanded), because some
Content-Security-Policy settings disable inline CSS.
Setting it the style with the `.css` method allows the output to be used
in more places.
This has the primary advantage of not interfering with browser default
behavior for links like being able to cmd/ctrl+click on a result to open
the result in a new tab but leave the current page as-is (previous
behavior both opened a new tab and changed the current tab's location to
the result's)
