bors [Mon, 20 Mar 2017 05:36:36 +0000 (05:36 +0000)]
Auto merge of #40281 - jimmycuadra:try-from-from-str, r=aturon
Rename TryFrom's associated type and implement str::parse using TryFrom.
Per discussion on the tracking issue, naming `TryFrom`'s associated type `Error` is generally more consistent with similar traits in the Rust ecosystem, and what people seem to assume it should be called. It also helps disambiguate from `Result::Err`, the most common "Err".
See https://github.com/rust-lang/rust/issues/33417#issuecomment-269108968.
`TryFrom<&str>` and `FromStr` are equivalent, so have the latter provide the former to ensure that. Using `TryFrom` in the implementation of `str::parse` means types that implement either trait can use it. When we're ready to stabilize `TryFrom`, we should update `FromStr` to
suggest implementing `TryFrom<&str>` instead for new code.
See https://github.com/rust-lang/rust/issues/33417#issuecomment-277175994
and https://github.com/rust-lang/rust/issues/33417#issuecomment-277253827.
Corey Farwell [Mon, 20 Mar 2017 00:51:10 +0000 (20:51 -0400)]
Rollup merge of #40554 - nrc:rls-data, r=alexcrichton
Use rls-data crate
This basically pulls out a bunch of data structures used by save-analysis for serialization into an external crate, and pulls that crate in using Rustbuild. The RLS can then share these data structures with the compiler which in some cases will allow more efficient communication between the compiler and the RLS (i.e., without serialisation).
Along the way, I have to pull in rls-span, which is the RLS's way of defining spans (more type-safe than the compiler's built-in way). This is basically just to convert from compiler spans to RLS spans.
I also pull in the crates.io version of rustc-serialize, which is a bit annoying, but seems to be the only way to have serialisable data in an external crate. To make this work, all of the save-analysis crate has to use this version too (cc #40527).
Finally I pull in a line from #40347 to make the unstable crate checking stuff working.
There are a lot of changes to save-analysis but they are all mechanical and trivial - changing from using `From` to `Into` (because of orphan rules) being the main thing.
Corey Farwell [Mon, 20 Mar 2017 00:51:09 +0000 (20:51 -0400)]
Rollup merge of #40532 - jseyfried:improve_tokenstream_quoter, r=nrc
macros: improve the `TokenStream` quoter
This PR
- renames the `TokenStream` quoter from `qquote!` to `quote!`,
- uses `$` instead of `unquote` (e.g. `let toks: TokenStream = ...; quote!([$toks])`),
- allows unquoting `Token`s as well as `TokenTree`s and `TokenStream`s (fixes #39746), and
- to preserve syntactic space, requires that `$` be followed by
- a single identifier to unquote, or
- another `$` to produce a literal `$`.
Corey Farwell [Mon, 20 Mar 2017 00:51:08 +0000 (20:51 -0400)]
Rollup merge of #40521 - TimNN:panic-free-shift, r=alexcrichton
Implemente overflowing_sh* with new unchecked_sh* intrinsics
Also update some 128 bit builtins to not rely on the constant evaluator to avoid checked operations.
Fixes #40508.
cc @nagisa, @alexcrichton
Note: I still have a build running to see if the 128 bit changes worked (unoptimized builds take *forever* to compile), however at least the overflowing builtins no longer reference `core::panicking::panic`.
Corey Farwell [Mon, 20 Mar 2017 00:51:07 +0000 (20:51 -0400)]
Rollup merge of #40398 - eddyb:struct-hint, r=nikomatsakis
Propagate expected type hints through struct literals.
Partial fix for #31260 to maximize backwards-compatibility, i.e. the hint is provided but not coerced to.
The added test works because `{...; x}` with a hint of `T` coerces `x` to `T`, and the reasoning why that is slightly different has to do with DSTs: `&Struct { tail: [x] }: &Struct<[T]>` has a hint of `[T]` for `[x]`, but the inferred type should be `[T; 1]` to succeed later, so `[x]` shouldn't be *forced* to be `[T]`.
*However*, implementing that complete behavior in a backwards-compatible way may be non-trivial, and has not yet been fully investigated, while this PR fixes #40355 and can be backported.
Corey Farwell [Mon, 20 Mar 2017 00:51:06 +0000 (20:51 -0400)]
Rollup merge of #40281 - jimmycuadra:try-from-from-str, r=aturon
Rename TryFrom's associated type and implement str::parse using TryFrom.
Per discussion on the tracking issue, naming `TryFrom`'s associated type `Error` is generally more consistent with similar traits in the Rust ecosystem, and what people seem to assume it should be called. It also helps disambiguate from `Result::Err`, the most common "Err".
See https://github.com/rust-lang/rust/issues/33417#issuecomment-269108968.
`TryFrom<&str>` and `FromStr` are equivalent, so have the latter provide the former to ensure that. Using `TryFrom` in the implementation of `str::parse` means types that implement either trait can use it. When we're ready to stabilize `TryFrom`, we should update `FromStr` to
suggest implementing `TryFrom<&str>` instead for new code.
See https://github.com/rust-lang/rust/issues/33417#issuecomment-277175994
and https://github.com/rust-lang/rust/issues/33417#issuecomment-277253827.
Corey Farwell [Mon, 20 Mar 2017 00:51:06 +0000 (20:51 -0400)]
Rollup merge of #40241 - Sawyer47:fix-39997, r=alexcrichton
Change how the `0` flag works in format!
Now it always implies right-alignment, so that padding zeroes are placed after the sign (if any) and before the digits. In other words, it always takes precedence over explicitly specified `[[fill]align]`. This also affects the '#' flag: zeroes are placed after the prefix (0b, 0o, 0x) and before the digits.
Here's a short summary of how similar format strings work in Python and Rust:
bors [Sun, 19 Mar 2017 21:02:53 +0000 (21:02 +0000)]
Auto merge of #39799 - dpc:create_dir_all, r=alexcrichton
Fix race condition in fs::create_dir_all
The code would crash if the directory was created after create_dir_all
checked whether the directory already existed. This was contrary to
the documentation which claimed to create the directory if it doesn't
exist, implying (but not stating) that there would not be a failure
due to the directory existing.
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.
Ignore the type of error altogether. The rationale is: it doesn't matter
what was the problem if the directory is there. In the previous versions
if the directory was there already we wouldn't even attempt to create
it, so we wouldn't know about the problem neither.
Make test path length smaller in `concurrent_recursive_mkdir` test.
David Roundy [Tue, 1 Dec 2015 22:29:56 +0000 (17:29 -0500)]
Fix race condition in fs::create_dir_all
It is more robust to not fail if any directory in a path was created
concurrently. This change lifts rustc internal `create_dir_racy` that
was created to handle such conditions to be new `create_dir_all`
implementation.
Ariel Ben-Yehuda [Mon, 13 Mar 2017 23:08:21 +0000 (01:08 +0200)]
translate drop glue using MIR
Drop of arrays is now translated in trans::block in an ugly way that I
should clean up in a later PR, and does not handle panics in the middle
of an array drop, but this commit & PR are growing too big.
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?