Corey Farwell [Sun, 19 Mar 2017 14:18:21 +0000 (10:18 -0400)]
Rollup merge of #40621 - jswalden:dependant-spelling-fix, r=sfackler
Fix a spelling error in HashMap documentation, and slightly reword surrounding text for precision
Noticed while reading docs just now.
It's possible that the prior wording *meant* to state that the seed's randomness depends on the exact instant that the system RNG was created, I guess. But unless there's an API guarantee that this is the case, the wording seems over-precise. Is there a formal API guarantee that would forbid, say, the system RNG from generating all output using the Intel RDRAND instruction? I don't think the quality of output in that case would depend on when the RNG was created. Yet it seems to me like it could well be a valid source of randomness when computing the initial seed.
For that reason, tying the randomness of the seed, to the quality of the RNG's output *at the precise instant the seed is computed*, seems less confining. That instantaneous quality level could be determined by the quality at the instant the RNG was created -- but instantaneous quality need not be low for that precise reason.
Corey Farwell [Sun, 19 Mar 2017 14:18:19 +0000 (10:18 -0400)]
Rollup merge of #40603 - QuietMisdreavus:slice-ptr-docs, r=GuillaumeGomez
minor wording tweak to slice::{as_ptr, as_mut_ptr}
Per #37334, the slice-as-pointer methods mentioned that "modifying the slice may cause its buffer to be reallocated", when in fact modifying the *slice* itself would cause no such change. (It is a borrow, after all!) This is a tweak to the wording of that line to stress it's the *collection* that could cause the buffer to be reallocated.
Corey Farwell [Sun, 19 Mar 2017 14:18:13 +0000 (10:18 -0400)]
Rollup merge of #40445 - estebank:issue-18150, r=jonathandturner
Point to let when modifying field of immutable variable
Point at the immutable local variable when trying to modify one of its
fields.
Given a file:
```rust
struct Foo {
pub v: Vec<String>
}
fn main() {
let f = Foo { v: Vec::new() };
f.v.push("cat".to_string());
}
```
present the following output:
```
error: cannot borrow immutable field `f.v` as mutable
--> file.rs:7:13
|
6 | let f = Foo { v: Vec::new() };
| - this should be `mut`
7 | f.v.push("cat".to_string());
| ^^^
Corey Farwell [Sun, 19 Mar 2017 14:18:12 +0000 (10:18 -0400)]
Rollup merge of #40441 - tschottdorf:promotable-rfc, r=eddyb
Add feature gate for rvalue-static-promotion
Probably needs more tests (which ones?) and there may be other things that need to be done. Also not sure whether the version that introduces the flag is really `1.15.1`.
bors [Sun, 19 Mar 2017 01:40:57 +0000 (01:40 +0000)]
Auto merge of #40538 - aturon:stab-1.17, r=alexcrichton
Library stabilizations for 1.17
Details of the stabilizations are available in the commits. Includes only library stabilizations; there are a couple of compiler stabilizations that should also be done for 1.17.
Will need a beta backport, which I will create after approval.
bors [Sat, 18 Mar 2017 03:31:58 +0000 (03:31 +0000)]
Auto merge of #40507 - alexcrichton:static-libcurl, r=brson
travis: Ensure cargo links libcurl statically
We don't want a dynamic dependency in the library that we ship, so link it
statically by configuring curl-sys's build script to not pick up the system
version via pkg-config.
Corey Farwell [Fri, 17 Mar 2017 12:49:09 +0000 (08:49 -0400)]
Rollup merge of #40545 - alexcrichton:retry-download-openssl, r=nikomatsakis
rustbuild: Retry downloads of OpenSSL source
We need this to compile Cargo and we download it at build time, but as like all
other network requests it has a chance of failing. This commit moves the source
of the tarball to a mirror (S3 seems semi-more-reliable most of the time) and
also wraps the download in a retry loop.
Corey Farwell [Fri, 17 Mar 2017 12:49:05 +0000 (08:49 -0400)]
Rollup merge of #40514 - stjepang:inline-then-ordering, r=alexcrichton
Inline functions Ordering::{then, then_with}
@jongiddy noticed bad performance due to the lack of inlining on `then`
and `then_with`. I confirmed that inlining really is the culprit by
creating a custom `then` function and repeating his benchmark on my
machine with and without the `#[inline]` attribute.
The numbers were exactly the same on my machine without the attribute.
With `#[inline]` I got the same performance as I did with manually
inlined implementation.
Corey Farwell [Fri, 17 Mar 2017 12:49:03 +0000 (08:49 -0400)]
Rollup merge of #40505 - frewsxcv:hash-docs, r=alexcrichton
A few improvements to the `core::hash` top-level docs.
Primarily opened to address the concerns brought up in
https://github.com/rust-lang/rust/issues/40498.
* run rustfmt on code blocks
* use `DefaultHasher` instead of deprecated `SipHasher`
* rename `hash` to `calculate_hash` to prevent confusion with the `hash`
method
Corey Farwell [Fri, 17 Mar 2017 12:49:02 +0000 (08:49 -0400)]
Rollup merge of #40503 - swgillespie:thread-hack-removal, r=sfackler
std: remove a workaround for privacy limitations
`std::thread::Thread` implements a non-exported `NewThread` trait to allow for internal-only use of `Thread::new`. Nowadays we have `pub(crate)`, which accomplishes the same thing but much more idiomatically.
Rustdoc handles this correctly (I checked and I didn't see `Thread::new` on the rustdoc entry for `Thread` with this change), and the stage1 `rustc` emits the correct error still (I'm assuming that the stage1 compiler uses my `libstd`?):
```
$ ./build/x86_64-apple-darwin/stage1/bin/rustc test.rs
error: method `new` is private
--> test.rs:4:18
|
4 | let thread = thread::Thread::new(None);
| ^^^^^^^^^^^^^^^^^^^
Corey Farwell [Fri, 17 Mar 2017 12:49:01 +0000 (08:49 -0400)]
Rollup merge of #40500 - estebank:turbofish-help, r=pnkfelix
Point out correct turbofish usage on `Foo<Bar<Baz>>`
Whenever we parse a chain of binary operations, as long as the first
operation is `<` and the subsequent operations are either `>` or `<`,
present the following diagnostic help:
use `::<...>` instead of `<...>` if you meant to specify type arguments
This will lead to spurious recommendations on situations like
`2 < 3 < 4` but should be clear from context that the help doesn't apply
in that case.
Corey Farwell [Fri, 17 Mar 2017 12:49:00 +0000 (08:49 -0400)]
Rollup merge of #40499 - ericfindlay:master, r=steveklabnik
Corrected very minor documentation detail about Unicode and Japanese
Japanese half-width and full-width romaji characters do have upper and lowercase according Unicode (but other Japanese characters do not). For example,
` assert_eq!('\u{FF21}'.to_lowercase().collect::<String>(),"\u{FF41}");`
Corey Farwell [Fri, 17 Mar 2017 12:48:55 +0000 (08:48 -0400)]
Rollup merge of #40466 - projektir:outdated_docs_highlighting, r=steveklabnik
Remove doc about highlighting code in other languages #40301
This doesn't appear to be true any longer, so removing it to avoid confusion. See #40301
Thoughts:
- may be a good idea to remove "Let's discuss the details of these code blocks.", as there's not much being discussed at this point;
- does `text` still work?
Alex Crichton [Wed, 15 Mar 2017 14:13:59 +0000 (07:13 -0700)]
rustbuild: Retry downloads of OpenSSL source
We need this to compile Cargo and we download it at build time, but as like all
other network requests it has a chance of failing. This commit moves the source
of the tarball to a mirror (S3 seems semi-more-reliable most of the time) and
also wraps the download in a retry loop.
bors [Wed, 15 Mar 2017 04:24:10 +0000 (04:24 +0000)]
Auto merge of #40009 - clarcharr:box_to_buf, r=alexcrichton
Leftovers from #39594; From<Box> impls
These are a few more impls that follow the same reasoning as those from #39594.
What's included:
* `From<Box<str>> for String`
* `From<Box<[T]>> for Vec<T>`
* `From<Box<CStr>> for CString`
* `From<Box<OsStr>> for OsString`
* `From<Box<Path>> for PathBuf`
* `Into<Box<str>> for String`
* `Into<Box<[T]>> for Vec<T>`
* `Into<Box<CStr>> for CString`
* `Into<Box<OsStr>> for OsString`
* `Into<Box<Path>> for PathBuf`
* `<Box<CStr>>::into_c_string`
* `<Box<OsStr>>::into_os_string`
* `<Box<Path>>::into_path_buf`
* Tracking issue for latter three methods + three from previous PR.
Currently, the opposite direction isn't doable with `From` (only `Into`) because of the separation between `liballoc` and `libcollections`. I'm holding off on those for a later PR.
Esteban Küber [Tue, 14 Mar 2017 02:07:47 +0000 (19:07 -0700)]
Point out correct turbofish usage on `Foo<Bar<Baz>>`
Whenever we parse a chain of binary operations, as long as the first
operation is `<` and the subsequent operations are either `>` or `<`,
present the following diagnostic help:
use `::<...>` instead of `<...>` if you meant to specify type arguments
This will lead to spurious recommendations on situations like
`2 < 3 < 4` but should be clear from context that the help doesn't apply
in that case.
Stjepan Glavina [Tue, 14 Mar 2017 13:01:01 +0000 (14:01 +0100)]
Inline functions Ordering::{then, then_with}
@jongiddy noticed bad performance due to the lack of inlining on `then`
and `then_with`. I confirmed that inlining really is the culprit by
creating a custom `then` function and repeating his benchmark on my
machine with and without the `#[inline]` attribute.
The numbers were exactly the same on my machine without the attribute.
With `#[inline]` I got the same performance as I did with manually
inlined implementation.
Simon Sapin [Mon, 6 Mar 2017 21:06:30 +0000 (22:06 +0100)]
Replace Utf8Error::resume_from with Utf8Error::error_len
Their relationship is:
* `resume_from = error_len.map(|l| l + valid_up_to)`
* error_len is always one of None, Some(1), Some(2), or Some(3).
When I started using resume_from I almost always ended up subtracting
valid_up_to to obtain error_len.
Therefore the latter is what should be provided in the first place.
Alex Crichton [Tue, 14 Mar 2017 05:13:37 +0000 (22:13 -0700)]
travis: Ensure cargo links libcurl statically
We don't want a dynamic dependency in the library that we ship, so link it
statically by configuring curl-sys's build script to not pick up the system
version via pkg-config.
Corey Farwell [Tue, 14 Mar 2017 04:42:44 +0000 (00:42 -0400)]
A few improvements to the `core::hash` top-level docs.
Primarily opened to address the concerns brought up in
https://github.com/rust-lang/rust/issues/40498.
* run rustfmt on code blocks
* use `DefaultHasher` instead of deprecated `SipHasher`
* rename `hash` to `calculate_hash` to prevent confusion with the `hash`
method
projects / rust.git / log