| Age | Commit message (Collapse) | Author | Lines |
|
This commit stabilizes and deprecates the FCP (final comment period) APIs for
the upcoming 1.7 beta release. The specific APIs which changed were:
Stabilized
* `Path::strip_prefix` (renamed from `relative_from`)
* `path::StripPrefixError` (new error type returned from `strip_prefix`)
* `Ipv4Addr::is_loopback`
* `Ipv4Addr::is_private`
* `Ipv4Addr::is_link_local`
* `Ipv4Addr::is_multicast`
* `Ipv4Addr::is_broadcast`
* `Ipv4Addr::is_documentation`
* `Ipv6Addr::is_unspecified`
* `Ipv6Addr::is_loopback`
* `Ipv6Addr::is_unique_local`
* `Ipv6Addr::is_multicast`
* `Vec::as_slice`
* `Vec::as_mut_slice`
* `String::as_str`
* `String::as_mut_str`
* `<[T]>::clone_from_slice` - the `usize` return value is removed
* `<[T]>::sort_by_key`
* `i32::checked_rem` (and other signed types)
* `i32::checked_neg` (and other signed types)
* `i32::checked_shl` (and other signed types)
* `i32::checked_shr` (and other signed types)
* `i32::saturating_mul` (and other signed types)
* `i32::overflowing_add` (and other signed types)
* `i32::overflowing_sub` (and other signed types)
* `i32::overflowing_mul` (and other signed types)
* `i32::overflowing_div` (and other signed types)
* `i32::overflowing_rem` (and other signed types)
* `i32::overflowing_neg` (and other signed types)
* `i32::overflowing_shl` (and other signed types)
* `i32::overflowing_shr` (and other signed types)
* `u32::checked_rem` (and other unsigned types)
* `u32::checked_neg` (and other unsigned types)
* `u32::checked_shl` (and other unsigned types)
* `u32::saturating_mul` (and other unsigned types)
* `u32::overflowing_add` (and other unsigned types)
* `u32::overflowing_sub` (and other unsigned types)
* `u32::overflowing_mul` (and other unsigned types)
* `u32::overflowing_div` (and other unsigned types)
* `u32::overflowing_rem` (and other unsigned types)
* `u32::overflowing_neg` (and other unsigned types)
* `u32::overflowing_shl` (and other unsigned types)
* `u32::overflowing_shr` (and other unsigned types)
* `ffi::IntoStringError`
* `CString::into_string`
* `CString::into_bytes`
* `CString::into_bytes_with_nul`
* `From<CString> for Vec<u8>`
* `From<CString> for Vec<u8>`
* `IntoStringError::into_cstring`
* `IntoStringError::utf8_error`
* `Error for IntoStringError`
Deprecated
* `Path::relative_from` - renamed to `strip_prefix`
* `Path::prefix` - use `components().next()` instead
* `os::unix::fs` constants - moved to the `libc` crate
* `fmt::{radix, Radix, RadixFmt}` - not used enough to stabilize
* `IntoCow` - conflicts with `Into` and may come back later
* `i32::{BITS, BYTES}` (and other integers) - not pulling their weight
* `DebugTuple::formatter` - will be removed
* `sync::Semaphore` - not used enough and confused with system semaphores
Closes #23284
cc #27709 (still lots more methods though)
Closes #27712
Closes #27722
Closes #27728
Closes #27735
Closes #27729
Closes #27755
Closes #27782
Closes #27798
|
|
|
|
|
|
|
|
This expands the code which generates unique IDs for Markdown headers within a single block to each rendered page.
fixes #25001
fixes #29449
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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).
|
|
|
|
Stricter checking + enforcement of invariants at compile time
|
|
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.
|
|
they are being used as an opaque "position identifier"
|
|
|
|
|
|
|
|
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.
|
|
This could be a [breaking-change] if your lint or syntax extension (is that even possible?) uses HIR attributes or literals.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
Closes #25976.
|
|
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 #22442
Fixes #24417
Fixes #25769
|
|
Yes, it's allowed. Example:
type MapFn<I, B> where I: Iterator = Map<I, fn(I::Item) -> B>;
Fixes #25769
|
|
Fixes #24575
|
|
|
|
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.
|