This patch implements the plan described in https://internals.rust-lang.org/t/privacy-and-its-interaction-with-docs-lints-and-stability/2880 with one deviation.
It turns out, that rustdoc needs the "directly public" set for its docs inlining logic, so the privacy pass have to produce three sets and not two. Three is arguably too many, so I merged them in one map:
`public_items/exported_items/reachable_items: NodeSet => access_levels: NodeMap<AccessLevel>`
r? @alexcrichton
This PR solves the following issues (or at least help users to understand the problem):
```Rust
#![crate_name = "b"]
#![crate_type = "rlib"]
pub fn his_function_has_a_very_long_name_and_should_make_cargo_doc_explodes_because_it_will_want_to_make_a_filename_with_it_in_excess_of_the_max_filename_length_for_most_filesystem_this_is_not_yet_long_enough_i_need_moreis_function_has_a_very_long_name_and_should_make_cargo_doc_explodes_because_it_will_want_to_make_a_filename_with_it_in_excess_of_the_max_filename_length_for_most_filesystem_this_is_not_yet_long_enough_i_need_more_() {}
```
```Rust
#![crate_name = "b"]
#![crate_type = "rlib"]
pub struct his_function_has_a_very_long_name_and_should_make_cargo_doc_explodes_because_it_will_want_to_make_a_filename_with_it_in_excess_of_the_max_filename_length_for_most_filesystem_this_is_not_yet_long_enough_i_need_moreis_function_has_a_very_long_name_and_should_make_cargo_doc_explodes_because_it_will_want_to_make_a_filename_with_it_in_excess_of_the_max_filename_length_for_most_filesystem_this_is_not_yet_long_enough_i_need_more_;
```
For the maximum filename length chosen, @gkoz gave me [this link](http://unix.stackexchange.com/a/32834).
The output of rustdoc includes resources licensed under the SIL Open
Font License, the MIT license, and the Apache License 2.0. All of these
licenses permit redistribution provided that the license text is also
redistributed. Previously this was not the case, making rustdoc output
unsuitable for distribution by default. This resolves that problem by
including the license texts in rustdoc output.
See also: https://users.rust-lang.org/t/licensing-rustdoc-output/2880
paths, and construct paths for all definitions. Also, stop rewriting
DefIds for closures, and instead just load the closure data from
the original def-id, which may be in another crate.
The output of rustdoc includes resources licensed under the SIL Open
Font License, the MIT license, and the Apache License 2.0. All of these
licenses permit redistribution provided that the license text is also
redistributed. Previously this was not the case, making rustdoc output
unsuitable for distribution by default. This resolves that problem by
including the license texts in rustdoc output.
Many of these have long since reached their stage of being obsolete, so this
commit starts the removal process for all of them. The unstable features that
were deprecated are:
* cmp_partial
* fs_time
* hash_default
* int_slice
* iter_min_max
* iter_reset_fuse
* iter_to_vec
* map_in_place
* move_from
* owned_ascii_ext
* page_size
* read_and_zero
* scan_state
* slice_chars
* slice_position_elem
* subslice_offset
Some cases displayed negative impls as positive, and some were missing
where clauses. This factors all the impl formatting into one
function so the different cases can't get out of sync again.
The common pattern `iter::repeat(elt).take(n).collect::<Vec<_>>()` is
exactly equivalent to `vec![elt; n]`, do this replacement in the whole
tree.
(Actually, vec![] is smart enough to only call clone n - 1 times, while
the former solution would call clone n times, and this fact is
virtually irrelevant in practice.)
With the latter is provided by the `From` conversion trait, the former is now completely redundant. Their code is identical. Let’s deprecate now and plan to remove in the next cycle. (It’s `#[unstable]`.)
r? @alexcrichton
CC @nagisa
rustdoc: Associated type fixes
The first commit fixes a bug with "dud" items in the search index from
misrepresented `type` items in trait impl blocks.
For a trait *implementation* there are typedefs which are the types for
that particular trait and implementor. Skip these in the search index.
There were lots of dud items in the search index due to this (search for
Item, Iterator's associated type).
Add a boolean to clean::TypedefItem so that it tracks whether the it is
a type alias on its own, or if it's a `type` item in a trait impl.
The second commit fixes a bug that made signatures and where bounds
using associated types (if they were not on `Self`) incorrect.
The third commit fixes so that where clauses in type alias definititons
are shown.
Fixes#22442Fixes#24417Fixes#25769
For a trait *implementation* there are typedefs which are the types for
that particular trait and implementor. Skip these in the search index.
There were lots of dud items in the search index due to this (search for
Item, Iterator's associated type).
Add a boolean to clean::TypedefItem so that it tracks whether the it is
a type alias on its own, or if it's a `type` item in a trait impl.
Fixes#22442
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.
I've found that there are still huge amounts of occurrences of `task`s in the documentation. This PR tries to eliminate all of them in favor of `thread`.
This syntax was removed in b24a3b8 but references remained in the
grammar, the reference, rustdoc generation, and some auxiliary test
files that don't seem to have been used since 812637e.
An automated script was run against the `.rs` and `.md` files,
subsituting every occurrence of `task` with `thread`. In the `.rs`
files, only the texts in the comment blocks were affected.
My change in #24797 had a bug, described in that issue’s comments, and first discovered in issue #24918. This fixes it.
I tested this new `main.js` by changing the `main.js` content of [a rendered docs page](https://doc.rust-lang.org/std/option/) to this new content. The ‘[−]’ button worked again.
I am also including another related fix, because it would require manual merging if I made a separate pull request for it. The page-global ‘[−]’ button currently adds `#` to the end of the URL whenever it is clicked. I am changing its `href` from `#` to `javascript:void(0)` (the same as the `href` for section-specific ‘[−]’ links) to fix that.
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.)
Error was noted at 60643081 (L371)
I didn’t just put the content of the node on another line, because that would add spaces around the element content, messing up the JavaScript that checks what the content is.
So that when you click the link, the URL doesn’t get # appended to it.
The non-page-global docs toggle link, which is created in `main.js`, already uses this `href` value.
