Alex Crichton [Sun, 21 Dec 2014 08:04:26 +0000 (00:04 -0800)]
rollup merge of #20079: SimonSapin/string_push_ascii_fast_path
`String::push(&mut self, ch: char)` currently has a single code path that calls `Char::encode_utf8`. This adds a fast path for ASCII `char`s, which are represented as a single byte in UTF-8.
Benchmarks of stage1 libcollections at the intermediate commit show that the fast path very significantly improves the performance of repeatedly pushing an ASCII `char`, but does not significantly affect the performance for a non-ASCII `char` (where the fast path is not taken).
A benchmark of pushing a one-byte-long `&str` is added for comparison, but its performance [has varied a lot lately](https://github.com/rust-lang/rust/pull/19640#issuecomment-67741561). (When the input is fixed, `s.push_str("x")` could be used just as well as `s.push('x')`.)
Alex Crichton [Sun, 21 Dec 2014 08:04:25 +0000 (00:04 -0800)]
rollup merge of #20070: aturon/stab-2-clone
This patch marks `clone` stable, as well as the `Clone` trait, but
leaves `clone_from` unstable. The latter will be decided by the beta.
The patch also marks most manual implementations of `Clone` as stable,
except where the APIs are otherwise deprecated or where there is
uncertainty about providing `Clone`.
Alex Crichton [Sun, 21 Dec 2014 08:04:22 +0000 (00:04 -0800)]
rollup merge of #20066: aturon/stab-2-cell
This patch finalizes stabilization for the `cell` module, settling on
the current names `Cell`, `RefCell`, `UnsafeCell`, `Ref` and `RefMut`.
While we had considered improving these names, no one was able to
produce a truly compelling alternative.
There is one substantive change here: the `get` method of `UnsafeSell`
is now marked `unsafe`. Merely getting a raw pointer to the contents is
not, by itself, an unsafe operation. (Consider that you can always
safely turn a reference into a raw pointer, and that raw pointer may
then be aliased by subsequent references.)
Alex Crichton [Sun, 21 Dec 2014 08:04:21 +0000 (00:04 -0800)]
rollup merge of #20062: aturon/stab-2-ints
This small patch stabilizes the names of all integer modules (including
`int` and `uint`) and the `MIN` and `MAX` constants. The `BITS` and
`BYTES` constants are left unstable for now.
Alex Crichton [Sun, 21 Dec 2014 08:04:10 +0000 (00:04 -0800)]
rollup merge of #20027: michaelwoerister/for-loop-var
Back when for-loop iteration variables were just de-sugared into `let` bindings, debuginfo for them was created like for any other `let` binding. When the implementation approach for for-loops changed, we ceased having debuginfo for the iteration variable. This PR fixes this omission and adds a more prominent test case for it.
Also contains some minor, general cleanup of the debuginfo module.
Alex Crichton [Sun, 21 Dec 2014 08:04:08 +0000 (00:04 -0800)]
rollup merge of #20006: alexcrichton/no-more-empty-modules
This commit modifies rustdoc to not require these empty modules to be public in
the standard library. The modules still remain as a location to attach
documentation to, but the modules themselves are now private (don't have to
commit to an API). The documentation for the standard library now shows all of
the primitive types on the main index page.
Alex Crichton [Sun, 21 Dec 2014 08:04:08 +0000 (00:04 -0800)]
rollup merge of #19996: th0114nd/boolean-inden
The current indentation level would indicate that Boolean literals are on the same level as Integer and Float literals under Number literals, unindenting moves it to the same scope as Character and string literals, Byte and byte string literals, and Number literals under Literals.
Alex Crichton [Sun, 21 Dec 2014 08:04:05 +0000 (00:04 -0800)]
rollup merge of #19980: erickt/cleanup-serialize
This brings over some changes from [rustc-serialize](https://github.com/rust-lang/rustc-serialize). It makes sense to keep the two in sync until we finally remove libserialize, just to make sure they don't diverge from each other.
Alex Crichton [Sun, 21 Dec 2014 08:04:02 +0000 (00:04 -0800)]
rollup merge of #19969: aturon/inherit-trait-stab
There is currently no way to specify the stability level for a trait
impl produced by `deriving`. This patch is a stopgap solution that:
* Turns of stability inheritance for trait impls, and
* Uses the stability level of the *trait* if no level is directly
specified.
That is, manual trait impls may still provide a directly stability
level, but `deriving` will use the level of the trait. While not a
perfect solution, it should be good enough for 1.0 API stabilization, as
we will like *remove* any unwanted impls outright.
Alex Crichton [Sun, 21 Dec 2014 08:04:02 +0000 (00:04 -0800)]
rollup merge of #19966: steveklabnik/remove_l10n
@brson suggested that I remove this stuff in https://github.com/rust-lang/rust/pull/19897/files#r22014810, but it seems more appropriate to do separate from that.
Alex Crichton [Sun, 21 Dec 2014 08:04:01 +0000 (00:04 -0800)]
rollup merge of #19965: japaric/remove-wrong-add
TL;DR I wrongly implemented these two ops, namely `"prefix" + "suffix".to_string()` gives back `"suffixprefix"`. Let's remove them.
The correct implementation of these operations (`lhs.clone().push_str(rhs.as_slice())`) is really wasteful, because the lhs has to be cloned and the rhs gets moved/consumed just to be dropped (no buffer reuse). For this reason, I'd prefer to drop the implementation instead of fixing it. This leaves us with the fact that you'll be able to do `String + &str` but not `&str + String`, which may be unexpected.
Alex Crichton [Sun, 21 Dec 2014 08:04:01 +0000 (00:04 -0800)]
rollup merge of #19961: alexcrichton/second-pass-result
This commit, like the second pass of `Option`, largely just stablizes the
existing functionality after renaming a few iterators.
The specific actions taken were:
* The `Ok` and `Err` variants were marked `#[stable]` as the stability
inheritance was since removed.
* The `as_mut` method is now stable.
* The `map` method is now stable
* The `map_err` method is now stable
* The `iter`, `iter_mut`, and `into_iter` methods now returned structures named
after the method of iteration. The methods are also now all stable.
* The `and_then` method is now stable.
* The `or_else` method is now stable.
* The `unwrap` family of functions are now all stable: `unwrap_or`,
`unwrap_or_else`, `unwrap`, and `unwrap_err`.
There is a possible open extension to `Result::{and, and_then}` to make the
return type further generic over `FromError` (as proposed in #19078), but this
is a backwards compatible change due to the usage of default type parameters,
which makes the two functions safe to stabilize now regardless of the outcome of
that issue.
Alex Crichton [Sun, 21 Dec 2014 08:04:00 +0000 (00:04 -0800)]
rollup merge of #19932: elszben/master
First attempt to contribute to rust (and using github). This commit adds a few examples to std::io::TempDir. The examples seem to look okay (in my browser) and make check also passes.
Alex Crichton [Sun, 21 Dec 2014 08:03:59 +0000 (00:03 -0800)]
rollup merge of #19898: Aatch/issue-19684
#16081 fixed an issue where a nested return statement would cause incorrect behaviour due to the inner return writing over the return stack slot that had already been written too. However, the check was very broad and picked many cases that wouldn't ever be affected by this issue.
As a result, the number of allocas increased dramatically and therefore stack-size increased. LLVM is not able to remove all of the extraneous allocas. Any code that had multiple return values in a compound expression at the end of a function (including loops) would be hit by the issue.
The check now uses a control-flow graph to only consider the case when the inner return is executed conditionally. By itself, this narrowed definition causes #15763 to return, so the control-flow graph is also used to avoid passing the return slot as a destination when the result won't be used.
This change allows the stack-size of the main rustc task to be reduced to 8MB from 32MB.
Alex Crichton [Sun, 21 Dec 2014 08:03:58 +0000 (00:03 -0800)]
rollup merge of #19823: iKevinY/doc-fixes
I was reading through the Rust Guide (hopefully looking to learn some Rust), and I figured it would be a good idea to open a pull request with some of the errata I noticed along the way. Most of the changes are pretty mundane, but there are a couple that might raise a bit of discussion.
### Punctuation outside of 'key term' quotes
This is something that was inconsistent in the Guide. While the convention in American English is to place punctuation immediately following a quotation mark *inside* the quotation mark, it seems strange to do this with 'key terms', considering they are not a true quotation.
### Changed comment placement in 17.2 code block
This is what the code block in [17.2 — Ownership, borrowing, and lifetimes](http://doc.rust-lang.org/guide.html#ownership,-borrowing,-and-lifetimes) looks like in fullscreened Safari 8:
![screen shot 2014-12-13 at 2 48 47 pm](https://cloud.githubusercontent.com/assets/2434728/5425704/2fff3bf0-82d7-11e4-8c8f-d594acde8937.png)
Some of the comments extend *just* too far, causing them to bleed into the next line, so I moved a few of them above the relevant lines of code to avoid this.
bors [Sun, 21 Dec 2014 15:42:42 +0000 (15:42 +0000)]
auto merge of #19961 : alexcrichton/rust/second-pass-result, r=aturon
This commit, like the second pass of `Option`, largely just stablizes the
existing functionality after renaming a few iterators.
The specific actions taken were:
* The `Ok` and `Err` variants were marked `#[stable]` as the stability
inheritance was since removed.
* The `as_mut` method is now stable.
* The `map` method is now stable
* The `map_err` method is now stable
* The `iter`, `iter_mut`, and `into_iter` methods now returned structures named
after the method of iteration. The methods are also now all stable.
* The `and_then` method is now stable.
* The `or_else` method is now stable.
* The `unwrap` family of functions are now all stable: `unwrap_or`,
`unwrap_or_else`, `unwrap`, and `unwrap_err`.
There is a possible open extension to `Result::{and, and_then}` to make the
return type further generic over `FromError` (as proposed in #19078), but this
is a backwards compatible change due to the usage of default type parameters,
which makes the two functions safe to stabilize now regardless of the outcome of
that issue.
bors [Sun, 21 Dec 2014 07:22:45 +0000 (07:22 +0000)]
auto merge of #19946 : cgaebel/rust/hashmap-drain-iter, r=gankro
It is useful to move all the elements out of a hashmap without deallocating
the underlying buffer. It came up in IRC, and this patch implements it as
`drain`.
Simon Sapin [Sat, 20 Dec 2014 17:17:58 +0000 (17:17 +0000)]
Add String::push_with_ascii_fast_path, bench it against String::push
`String::push(&mut self, ch: char)` currently has a single code path
that calls `Char::encode_utf8`.
Perhaps it could be faster for ASCII `char`s, which are represented as
a single byte in UTF-8.
This commit leaves the method unchanged,
adds a copy of it with the fast path,
and adds benchmarks to compare them.
Results show that the fast path very significantly improves the performance
of repeatedly pushing an ASCII `char`,
but does not significantly affect the performance for a non-ASCII `char`
(where the fast path is not taken).
Output of `make check-stage1-collections NO_REBUILD=1 PLEASE_BENCH=1 TESTNAME=string::tests::bench_push`
A benchmark of pushing a one-byte-long `&str` is added for comparison,
but its performance [has varied a lot lately](
https://github.com/rust-lang/rust/pull/19640#issuecomment-67741561).
(When the input is fixed, `s.push_str("x")` could be used
instead of `s.push('x')`.)
bors [Sat, 20 Dec 2014 13:52:27 +0000 (13:52 +0000)]
auto merge of #19900 : alexcrichton/rust/compiler-flags, r=cmr
This commit shuffles around some CLI flags of the compiler to some more stable
locations with some renamings. The changes made were:
* The `-v` flag has been repurposes as the "verbose" flag. The version flag has
been renamed to `-V`.
* The `-h` screen has been split into two parts. Most top-level options (not
all) show with `-h`, and the remaining options (generally obscure) can be
shown with `--help -v` which is a "verbose help screen"
* The `-V` flag (version flag now) has lost its argument as it is now requested
with `rustc -vV` "verbose version".
* The `--emit` option has had its `ir` and `bc` variants renamed to `llvm-ir`
and `llvm-bc` to emphasize that they are LLVM's IR/bytecode.
* The `--emit` option has grown a new variant, `dep-info`, which subsumes the
`--dep-info` CLI argument. The `--dep-info` flag is now deprecated.
* The `--parse-only`, `--no-trans`, `--no-analysis`, and `--pretty` flags have
moved behind the `-Z` family of flags.
* The `--debuginfo` and `--opt-level` flags were moved behind the top-level `-C`
flag.
* The `--print-file-name` and `--print-crate-name` flags were moved behind one
global `--print` flag which now accepts one of `crate-name`, `file-names`, or
`sysroot`. This global `--print` flag is intended to serve as a mechanism for
learning various metadata about the compiler itself.
* The top-level `--pretty` flag was moved to a number of `-Z` options.
No warnings are currently enabled to allow tools like Cargo to have time to
migrate to the new flags before spraying warnings to all users.
Aaron Turon [Sat, 20 Dec 2014 08:35:06 +0000 (00:35 -0800)]
Stabilize clone
This patch marks `clone` stable, as well as the `Clone` trait, but
leaves `clone_from` unstable. The latter will be decided by the beta.
The patch also marks most manual implementations of `Clone` as stable,
except where the APIs are otherwise deprecated or where there is
uncertainty about providing `Clone`.
Aaron Turon [Sat, 20 Dec 2014 07:47:46 +0000 (23:47 -0800)]
Stabilize cell
This patch finalizes stabilization for the `cell` module, settling on
the current names `Cell`, `RefCell`, `UnsafeCell`, `Ref` and `RefMut`.
While we had considered improving these names, no one was able to
produce a truly compelling alternative.
There is one substantive change here: the `get` method of `UnsafeSell`
is now marked `unsafe`. Merely getting a raw pointer to the contents is
not, by itself, an unsafe operation. (Consider that you can always
safely turn a reference into a raw pointer, and that raw pointer may
then be aliased by subsequent references.)
Aaron Turon [Sat, 20 Dec 2014 06:28:12 +0000 (22:28 -0800)]
Stabilize integer modules
This small patch stabilizes the names of all integer modules (including
`int` and `uint`) and the `MIN` and `MAX` constants. The `BITS` and
`BYTES` constants are left unstable for now.
bors [Sat, 20 Dec 2014 01:12:19 +0000 (01:12 +0000)]
auto merge of #19640 : aliblong/rust/power_of_two_reform, r=Gankro
The `is_power_of_two()` method of the `UnsignedInt` trait currently returns `true` for `self == 0`. Zero is not a power of two, assuming an integral exponent `k >= 0`. I've therefore moved this functionality to the new method `is_power_of_two_or_zero()` and reformed `is_power_of_two()` to return false for `self == 0`.
To illustrate the usefulness of the existence of both functions, consider `HashMap`. Its capacity must be zero or a power of two; conversely, it also requires a (non-zero) power of two for key and val alignment.
Also, added a small amount of documentation regarding #18604.
Alex Crichton [Wed, 17 Dec 2014 20:10:13 +0000 (12:10 -0800)]
std: Second pass stabilization of Result<T, E>
This commit, like the second pass of `Option`, largely just stablizes the
existing functionality after renaming a few iterators.
The specific actions taken were:
* The `Ok` and `Err` variants were marked `#[stable]` as the stability
inheritance was since removed.
* The `as_mut` method is now stable.
* The `map` method is now stable
* The `map_err` method is now stable
* The `iter`, `iter_mut`, and `into_iter` methods now returned structures named
after the method of iteration. The methods are also now all stable.
* The `and_then` method is now stable.
* The `or_else` method is now stable.
* The `unwrap` family of functions are now all stable: `unwrap_or`,
`unwrap_or_else`, `unwrap`, and `unwrap_err`.
There is a possible open extension to `Result::{and, and_then}` to make the
return type further generic over `FromError` (as proposed in #19078), but this
is a backwards compatible change due to the usage of default type parameters,
which makes the two functions safe to stabilize now regardless of the outcome of
that issue.