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).
Stricter checking of stability attributes + enforcement of their invariants at compile time
(+ removed dead file librustc_front/attr.rs)
I intended to enforce use of `reason` for unstable items as well (it normally presents for new items), but it turned out too intrusive, many older unstable items don't have `reason`s.
r? @aturon
I'm studying how stability works and do some refactoring along the way, so it's probably not the last PR.
The text says it's a vector of floats, but the code actually uses a vector of integers. The type of the Vec doesn't really matter, so I just cut it from the text.
Fixes issue #29077.
There **are** API changing guidelines in the RFCs, so it might be prudent to put those there. But I'm leaving that up to another person. This PR just removes bad documentation.
The implementation for `into_inner` was a bit more complex than I had hoped for---is there any simpler, less unsafe way of getting around the fact that one can't move out of a `Drop` struct?
See #28968 and rust-lang/rfcs#1269 .
The text says it's a vector of floats, but the code actually uses a vector of integers. The type of the Vec doesn't really matter, so I just cut it from the text.
This commit adds `#[derive(Clone)]` to `std::fs::Metadata`, making that struct cloneable. Although the exact contents of that struct differ between OSes, they all have it contain only value types, meaning that the data can be re-used without repercussions.
It also adds `#[derive(Clone)]` to every type used by that struct across all OSes, including the various Unix `stat` structs and Windows's `WIN32_FILE_ATTRIBUTE_DATA`.
This stems from my comment here: https://github.com/rust-lang/rfcs/issues/939#issuecomment-140524439
Regarding [#29063 _[Docs] Terminology inconsistency between 'iterator adapters' and 'iterator adaptors'_](https://github.com/rust-lang/rust/issues/29063) :
This PR replaces 'iterator adapters' appearances (in TRPL book) to 'iterator adaptors', thus embracing the terminology used along the API docs and achieving consistency between both sources.
Before this commit, the first "A Rust library" code sample produced
the following compilation warning:
```
test.rs:7:22: 7:36 warning: unnecessary parentheses around `for` head
expression, #[warn(unused_parens)] on by default
test.rs:7 for _ in (0..5_000_000) {
```
This commit just removes the parens around the range 0..5_000_000 thereby removing the compilation warning.
Fixes#28676.
There doesn't seem to be a good way to add a test for this, but I tested the repro in #28676 and confirmed it now yields the correct result.
Regarding #29063: Replace 'iterator adapters' appearances to
'iterator adaptors', thus embracing the terminology used along the
API docs and achieving consistency between both sources.
