| Age | Commit message (Collapse) | Author | Lines |
|---|
|
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)?
---
|
|
|
|
Fixes #22325
|
|
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.
|
|
Fixes #22325
|
|
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
|
|
ECMAScript 6 isn't really supported anywhere
Closes #20681
|
|
|
|
Fixes #17332.
|
|
This series of commits deals with broken links to the source code. It also refactors some repetitive codes from Rustdoc. The most important commit, 1cb1f00d40f000ac7633b62a603db4fcea835ca6, 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 bda97e8557820cc4ec13645dbdf976e5ccaa0ce1 (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
|
|
Fixes #17332.
|
|
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.
|
|
Fixes #18354.
|
|
At the same time, migrate statics to constants.
|
|
|
|
This is done by adding a new field to the `DefTy` variant of `middle::def::Def`,
which also clarifies an error message in the process.
Closes #16712.
|
|
This needs a clone otherwise each successive insertion detaches `toggle`
from the previous position.
Fixes #17125.
|
|
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)
|
|
fixes #16385
fixes #16271
|
|
fixes #16384
|
|
All doccomments are now collapsable via a nearby [-] button
Adds [collapse all] and [expand all] buttons to the top of all api pages
Tweaks some layout to accomadate this
|
|
This enables the docs search function to be more forgiving for spelling mistakes. The algorithm works as a dynamic programming algorithm to detect the minimum number of changes required to the search parameter string in order to match any string in the search index. If the number of changes is less then a threshold (currently defined as 3), then the search parameter will be included as it is a possible misspelling of the word. Any results returned by the algorithm are sorted by distance and are ranked lower than results that are partial or exact matches (aka the matches returned by the original search algorithm). Additionally, the increment in the for loops in this file were using one of three different ways to increment (`i += 1` `i++` and `++i`) so I just standardized it to `++i`.
As an example, consider searching for the word `String` and accidentally typing in `Strnig`. The old system would return no results because it is a misspelling, but the Levenshtein distance between these two inputs is only two, which means that this will return `String` as a result. Additionally, it will return a few other results such as `strong`, and `StdRng` because these are also similar to `Strnig`. Because of the ranking system though, this change should be unobtrusive to anyone that spells the words correctly, as those are still ranked first before any Levenshtein results.
|
|
* Makes dashboard width dynamic.
* Colors unmarked items.
* Gives overall crate percentages.
|
|
Apparently keypress doesn't quite work in all browsers due to some not invoking
the handler and jquery not setting the right `which` field in all circumstances.
According to http://stackoverflow.com/questions/2166771 switching over to
`keydown` works and it appears to do the trick. Tested in Safari, Firefox, and
Chrome.
Closes #15011
|
|
|
|
enables the docs search function to be more forgiving for spelling mistakes
|
|
Updated search bar to match help text.
Used correct, normalized hotkeys in search.
Updated shortcut menu with working shortcuts (tabs).
Changed height of search help.
|
|
* Change links to display:block for click larger targets
* Remove linebreaks due to extra space
* Adjust margins so that element spacing stays the same
* Sidebar item hover background colour chosen from <pre> styling
|
|
This grows a new option inside of rustdoc to add the ability to submit examples
to an external website. If the `--markdown-playground-url` command line option
or crate doc attribute `html_playground_url` is present, then examples will have
a button on hover to submit the code to the playground specified.
This commit enables submission of example code to play.rust-lang.org. The code
submitted is that which is tested by rustdoc, not necessarily the exact code
shown in the example.
Closes #14654
|
|
|
|
This commit adds support in rustdoc to recognize the `#[doc(primitive = "foo")]`
attribute. This attribute indicates that the current module is the "owner" of
the primitive type `foo`. For rustdoc, this means that the doc-comment for the
module is the doc-comment for the primitive type, plus a signal to all
downstream crates that hyperlinks for primitive types will be directed at the
crate containing the `#[doc]` directive.
Additionally, rustdoc will favor crates closest to the one being documented
which "implements the primitive type". For example, documentation of libcore
links to libcore for primitive types, but documentation for libstd and beyond
all links to libstd for primitive types.
This change involves no compiler modifications, it is purely a rustdoc change.
The landing pages for the primitive types primarily serve to show a list of
implemented traits for the primitive type itself.
The primitive types documented includes both strings and slices in a semi-ad-hoc
way, but in a way that should provide at least somewhat meaningful
documentation.
Closes #14474
|
|
When inlining documentation across crates, primitive implementors of traits were
not shown. This commit tweaks the infrastructure to treat primitive and
Path-like impls the same way, displaying all implementors everywhere.
cc #14462
|
|
|
|
These links work by hyperlinking back to the actual documentation page with a
query parameter which will be recognized and then auto-click the appropriate
[src] link.
|
|
Right now, when you look in the "Implementors" section for traits, you only see
implementors within that crate. This commit modifies that section to include
implementors from neighboring crates as well.
For example, the Container trait currently says that it is only implemented by
strings and slices, but it is in fact implemented by nearly all containers.
Implementation-wise, this change generates an "implementors cache" similarly to
the search index where each crate will append implementors to the files. When
the page for a trait is loaded, it will load its specific cache file, rendering
links for all upstream types which implement the trait.
|
|
When the values in html::item_type were updated, the JS definitions were
accidentally not updated as well.
Closes #14095
|
|
|
|
|
|
This essentially rewrites the sorting algorithm, which relied on
the implementation-defined handling of non-consistent sorting function
(cf. ECMA-262 5th edition, section 15.4.4.11)
and was also a bit inefficient.
The new criteria expands the prior criteria while adding these ones:
- The current crate is always preferred over other crates.
(Closes #13178)
- An item with a description is preferred over one without it,
if item names match. This is a heuristic assuming that
the documented item is more likely to be relevant.
- An item with no literal occurrence of search query is handled correctly.
|
|
Since the items roughly follow the lexical order, there are
many consecutive items with the same path value which can be
easily compressed.
For the library and compiler docs, this commit decreases
the index size by 26% and 6% before and after gzip, respectively.
|
|
|
|
`buildIndex` JS function recovers them into the original object form.
This greatly reduces the size of the uncompressed search index (27%),
while this effect is less visible after gzipped (~5%).
|
|
Has negligible improvements with gzip, but saves about 7% without it.
This also has an effect of changing the tie-breaking order of item types.
|
