I somehow missed a word behind the numbers while going through this section, don't know what the best approach would be though since "**available** addresses" sounds good to me, too".
instead of this panic:
```
thread '<main>' panicked at 'index out of bounds: the len is 1 but the
index is 1', src/libcollections/vec.rs:1110
```
It still panics, just like `-h` does, so it should be okay in this
regard.
As displayed before this commit, I found the book confusing in its
explanation of `#`-led comments in `rust` blocks. Possibly the
biggest confusion was because the many-dashes construct does not
become an HR element in the Markdown translator used, so things were
not being properly set off.
This change should more clearly show the as-rendered content as
rendered, and the as-coded content as code.
This commit stabilizes and deprecates library APIs whose FCP has closed in the
last cycle, specifically:
Stabilized APIs:
* `fs::canonicalize`
* `Path::{metadata, symlink_metadata, canonicalize, read_link, read_dir, exists,
is_file, is_dir}` - all moved to inherent methods from the `PathExt` trait.
* `Formatter::fill`
* `Formatter::width`
* `Formatter::precision`
* `Formatter::sign_plus`
* `Formatter::sign_minus`
* `Formatter::alternate`
* `Formatter::sign_aware_zero_pad`
* `string::ParseError`
* `Utf8Error::valid_up_to`
* `Iterator::{cmp, partial_cmp, eq, ne, lt, le, gt, ge}`
* `<[T]>::split_{first,last}{,_mut}`
* `Condvar::wait_timeout` - note that `wait_timeout_ms` is not yet deprecated
but will be once 1.5 is released.
* `str::{R,}MatchIndices`
* `str::{r,}match_indices`
* `char::from_u32_unchecked`
* `VecDeque::insert`
* `VecDeque::shrink_to_fit`
* `VecDeque::as_slices`
* `VecDeque::as_mut_slices`
* `VecDeque::swap_remove_front` - (renamed from `swap_front_remove`)
* `VecDeque::swap_remove_back` - (renamed from `swap_back_remove`)
* `Vec::resize`
* `str::slice_mut_unchecked`
* `FileTypeExt`
* `FileTypeExt::{is_block_device, is_char_device, is_fifo, is_socket}`
* `BinaryHeap::from` - `from_vec` deprecated in favor of this
* `BinaryHeap::into_vec` - plus a `Into` impl
* `BinaryHeap::into_sorted_vec`
Deprecated APIs
* `slice::ref_slice`
* `slice::mut_ref_slice`
* `iter::{range_inclusive, RangeInclusive}`
* `std::dynamic_lib`
Closes#27706Closes#27725
cc #27726 (align not stabilized yet)
Closes#27734Closes#27737Closes#27742Closes#27743Closes#27772Closes#27774Closes#27777Closes#27781
cc #27788 (a few remaining methods though)
Closes#27790Closes#27793Closes#27796Closes#27810
cc #28147 (not all parts stabilized)
This commit stabilizes and deprecates library APIs whose FCP has closed in the
last cycle, specifically:
Stabilized APIs:
* `fs::canonicalize`
* `Path::{metadata, symlink_metadata, canonicalize, read_link, read_dir, exists,
is_file, is_dir}` - all moved to inherent methods from the `PathExt` trait.
* `Formatter::fill`
* `Formatter::width`
* `Formatter::precision`
* `Formatter::sign_plus`
* `Formatter::sign_minus`
* `Formatter::alternate`
* `Formatter::sign_aware_zero_pad`
* `string::ParseError`
* `Utf8Error::valid_up_to`
* `Iterator::{cmp, partial_cmp, eq, ne, lt, le, gt, ge}`
* `<[T]>::split_{first,last}{,_mut}`
* `Condvar::wait_timeout` - note that `wait_timeout_ms` is not yet deprecated
but will be once 1.5 is released.
* `str::{R,}MatchIndices`
* `str::{r,}match_indices`
* `char::from_u32_unchecked`
* `VecDeque::insert`
* `VecDeque::shrink_to_fit`
* `VecDeque::as_slices`
* `VecDeque::as_mut_slices`
* `VecDeque::swap_remove_front` - (renamed from `swap_front_remove`)
* `VecDeque::swap_remove_back` - (renamed from `swap_back_remove`)
* `Vec::resize`
* `str::slice_mut_unchecked`
* `FileTypeExt`
* `FileTypeExt::{is_block_device, is_char_device, is_fifo, is_socket}`
* `BinaryHeap::from` - `from_vec` deprecated in favor of this
* `BinaryHeap::into_vec` - plus a `Into` impl
* `BinaryHeap::into_sorted_vec`
Deprecated APIs
* `slice::ref_slice`
* `slice::mut_ref_slice`
* `iter::{range_inclusive, RangeInclusive}`
* `std::dynamic_lib`
Closes#27706Closes#27725
cc #27726 (align not stabilized yet)
Closes#27734Closes#27737Closes#27742Closes#27743Closes#27772Closes#27774Closes#27777Closes#27781
cc #27788 (a few remaining methods though)
Closes#27790Closes#27793Closes#27796Closes#27810
cc #28147 (not all parts stabilized)
instead of this panic:
```
thread '<main>' panicked at 'index out of bounds: the len is 1 but the
index is 1', src/libcollections/vec.rs:1110
```
It still panics, just like `-h` does, so it should be okay in this
regard.
The new bots we have may conflict with one another on base ports, causing tests
to fail. For example the linux-musl-64-opt and linux-64-opt bots are using the
same base port right now, causing some spurious failures every now and then.
Previously, if you copied a signature from a trait definition such as:
```
fn foo<'a>(&'a Bar) -> bool {}
```
and moved it into an `impl`, there would be an error message:
"unexpected token `'a`"
Adding to the error message that a pattern is expected should help
users to find the actual problem with using a lifetime here.
PR for #28157. At the moment, `rustc` emits a warning when a bare semicolon is encountered (could also be a fail, but I think this is a backwards incompatible change).
Also I am not sure where the best place for a test for that warning would be. Seems run-pass tests do not check warnings.
Give preference to projections from where-clauses over those from trait definitions. This makes #28871 work again, though I think there's more to fix in this general area.
r? @arielb1
cc @brson (fixes regression)
The new bots we have may conflict with one another on base ports, causing tests
to fail. For example the linux-musl-64-opt and linux-64-opt bots are using the
same base port right now, causing some spurious failures every now and then.
Fixes#29184
This adds an error message for the use of the reserved `typeof` keyword, instead of reporting an ICE.
Also adds a `compile-fail` test.
I chose to add a `span_err` instead of removing to parser code, as to preserve the reservation of `typeof`.
It's possible that there is some meaning I'm not grasping from the headers "Traits bounds for generic functions" and "Traits bounds for generic structs", but they seem to me like they could be clearer and more grammatically correct.
Qualified paths allow full path after the `>::`. For example
```rust
<T as Foo>::U::generic_method::<f64>()
```
The example is taken from `test/run-pass/associated-item-long-paths.rs`.
{BTree,Hash}{Map,Set} will not update their key if it already exists, which
can matter with more complex keys. This behavior is now documented.
Fixes#26888
{BTree,Hash}{Map,Set} will not update their key if it already exists, which
can matter with more complex keys. This behavior is now documented.
Fixes#26888
Qualified paths allow full path after the `>::`. For example
```rust
<T as Foo>::U::generic_method::<f64>()
```
The example is taken from `test/run-pass/associated-item-long-paths.rs`.
Currently it is possible to do the following:
- define a module named `Foo` and then a unit or tuple struct also named `Foo`
- define any struct named `Foo` and then a module named `Foo`
This commit introduces a warning for both of these cases.
trait definitions, and give prefence to the former. This is consistent
with what we do for selection. It also works around a limitation
that was leading to #28871.
When reading this paragraph, the beginning Rust programmer is starting
to write a Hello World program. We have just told her to name the file
`main.rs`, and immediately afterward, a `hello_world.rs` is mentioned.
I changed this to an unrelated filename (incidentally one that appears
in this repository) to make it clear that this is just an example.
Also, wording it as a declarative sentence rather than an imperative one
further separates it from the Hello World instructions in this section.
r? @steveklabnik
(Let me know if I'm sending too many PRs -- I can batch up TRPL edits, say, per chapter, if that works better. Or I can just refrain from editing TRPL as I read through it, if these are not sufficiently useful.)
The paragraph here seemed confusing, so I reworded it. Also added
another possible reason why `curl | sh` might be objectionable to users.
r? @steveklabnik
The paragraph here seemed confusing, so I reworded it. Also added
another possible reason why `curl | sh` might be objectionable to users.
r? @steveklabnik
This is a pretty trivial change. My eye caught some inconsistent whitespace while perusing compiler errors tonight. Specifically, I changed `//correct` to `// correct`, and got rid of some trailing whitespace that isn't seen in other code snippets.
This commit expands the "supported platforms" section of the book to include
documentation on the tiers that Rust currently has as well as organizing all
supported platforms into these various tiers. Infrastructure improvements over
the next few months are likely to change the location of may of these platforms
over, but for now this should faithfully represent what we've got today!
When reading this paragraph, the beginning Rust programmer is starting
to write a Hello World program. We have just told her to name the file
`main.rs`, and immediately afterward, a `hello_world.rs` is mentioned.
I changed this to an unrelated filename (incidentally one that appears
in this repository) to make it clear that this is just an example.
Also, wording it as a declarative sentence rather than an imperative one
further separates it from the Hello World instructions in this section.
This commit expands the "supported platforms" section of the book to include
documentation on the tiers that Rust currently has as well as organizing all
supported platforms into these various tiers. Infrastructure improvements over
the next few months are likely to change the location of may of these platforms
over, but for now this should faithfully represent what we've got today!
Yay, markdown isn't standardized and rustbook's parser has subtle incompatibilities with Github's! So in the Github preview you don't see that this list fails to separate from the previous paragraph. I think this should fix it, but I didn't check.
This is a WIP PR for my implementation of drain over the VecDeque data structure supporting ranges. It brings the VecDeque drain implementation in line with Vec's.
Tests haven't been written for the new function yet.
The attributes are copied from the item for which the trait impl is derived
I think now we can close these two issues:
https://github.com/rust-lang/rust/issues/13054 - `allow`, `deny` etc. were already copied, now `stable` and `unstable` are copied as well.
https://github.com/rust-lang/rust/issues/18969 - I'm not sure this is needed, insta-stability were good enough so far, copied stability will be better. Nonetheless, it can be subsumed by some more general mechanism for supplying arbitrary not necessarily stability related attributes (for example `inline`) to derived impls and their methods (I haven't found an open issue for such mechanism).
r? @alexcrichton
This is for discoverability. If someone wants to know what `?Sized` means, then
Sized will be the only keyword they can use to search; so even though this is
technically a language matter, it makes sense to document it where it will be
looked for.
Remove leading newlines; replace lines containing only whitespace with empty lines; replace multiple trailing newlines with a single newline; remove trailing whitespace in lines.
This PR was created semiautomatically.
To augment the didactic effect, made placed the thread::sleep_ms call in the last example, so that there will be time for the other locks to happen; without this, I was unable to observe the deadlock in over 1,000 runs when there was no left-handed philosopher.
I wasn't sure whether `Ordering::Relaxed` meant `Monotonic` or `Unordered`, so I checked the compiler sources and found 206af38e74/src/librustc_trans/trans/intrinsic.rs (L846) which appears conclusive. Adding this answer to the documentation.
Due to the way iterators work, the std::iter module is chock full of
structs that you, humble Rust programmer, will never actually use.
However, they have URLs, and therefore get linked to, because they are
real structs that do exist.
So, rather than just have a tiny sentence about each one of them,
this patch adds links back to the functions and methods on Iterator
which actually create the structs, where helpful documentation already
exists.
`OsString` has these sorts of conversions, while `CString` has been missing them. I'm iffy on `into_string` simply because the return type would be better off as `FromUtf8Error<CString>`, which of course isn't generic 😢
Also should a different/new feature gate be used?
Remove leading newlines; replace lines containing only whitespace with empty lines; replace multiple trailing newlines with a single newline; remove trailing whitespace in lines
To augment the didactic effect, made placed the thread::sleep_ms call in the last example, so that there will be time for the other locks to happen; without this, I was unable to observe the deadlock in over 1,000 runs when there was no left-handed philosopher.
Fixes#29128
Most of the weird lifetime things and `inner` stuff seems like leftover cruft from `thread::scoped`. Should `JoinInner` just be removed/merged with `JoinHandle`?
Also is it okay to remove the `FnBox`? I'm not really sure why there were two allocations there...
Since it isn't possible to disable linkage of just GCC startup objects, we now need logic for finding libc installation directory and copying the required startup files (e.g. crt2.o) to rustlib directory.
Bonus change: use the `-nodefaultlibs` flag on Windows, thus paving the way to direct linker invocation.
Rather than injecting a local `_Unwind_Resume` into the current translation unit,
just replace `resume` instruction with a direct call the the `eh_unwind_resume` lang item.
This is likely to be more robust in the face of future LLVM changes, and also allows us to delegate
work back to libgcc's `_Unwind_Resume`.
This is for discoverability. If someone wants to know what ?Sized means, then
Sized will be the only keyword they can use to search; so even though this is
technically a language matter, it makes sense to document it where it will be
looked for.
This PR turns statically known erroneous code (e.g. numeric overflow) into a warning and continues normal code-generation to emit the same code that would have been generated without `check_const` detecting that the result can be computed at compile-time.
<del>It's not done yet, as I don't know how to properly emit a lint from trans. I can't seem to extract the real lint level of the item the erroneous expression is in.</del> It's an unconditional warning now.
r? @pnkfelix
cc @nikomatsakis
* [RFC 1229 text](https://github.com/rust-lang/rfcs/blob/master/text/1229-compile-time-asserts.md)
* RFC PR: rust-lang/rfcs#1229
* tracking issue: https://github.com/rust-lang/rust/issues/28238
The escaped form isn't pretty, but this should be a very rare error.
Having a general binary-escaping string creation function might be a
good idea, though.
Closes#29122
The escaped form isn't pretty, but this should be a very rare error.
Having a general binary-escaping string creation function might be a
good idea, though.
Closes#29122
When going through the docs, it is not clear that binary files cannot be tested. Additionally, it is hard to find the proper structure of a Rust crate and it took me several hours of looking through the docs to find the crates and modules section. I think we can link to it from here and it will be beneficial to those who are coming to the language.
While working on #28711 I found out that
* src/libcoretest/clone.rs
* src/libcoretest/fmt/float.rs
* src/libcoretest/intrinsics.rs
are not used. I am not sure if removing them is the right way to go. If it makes sense to keep (and fix and enable) them, I would be happy to update the PR.
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).
This change has two consequences:
1. It makes `Arc<T>` and `Rc<T>` covariant in `T`.
2. It causes the compiler to reject code that was unsound with respect
to dropck. See compile-fail/issue-29106.rs for an example of code that
no longer compiles. Because of this, this is a [breaking-change].
Fixes#29037.
Fixes#29106.
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.
When going through the docs, it is not clear that binary files cannot be tested. Additionally, it is hard to find the proper structure of a Rust crate and it took me several hours of looking through the docs to find the crates and modules section. I think we can link to it from here and it will be beneficial to those who are coming to the language.
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.
