Aaron Turon [Mon, 24 Nov 2014 03:21:17 +0000 (19:21 -0800)]
libs: merge librustrt into libstd
This commit merges the `rustrt` crate into `std`, undoing part of the
facade. This merger continues the paring down of the runtime system.
Code relying on the public API of `rustrt` will break; some of this API
is now available through `std::rt`, but is likely to change and/or be
removed very soon.
Clark Gaebel [Tue, 16 Dec 2014 22:45:03 +0000 (17:45 -0500)]
[collections] Adds `drain`: a way to sneak out the elements while clearing.
It is useful to move all the elements out of some collections without
deallocating the underlying buffer. It came up in IRC, and this patch
implements it as `drain`. This has been discussed as part of RFC 509.
bors [Fri, 19 Dec 2014 02:52:01 +0000 (02:52 +0000)]
auto merge of #19955 : Gankro/rust/kill-all-code, r=aturon
EnumSet lives on in libcollections so that librustc can still use it. This adds a direct dependency on libcollections to librustc and libserialize.
Should not be merged until https://github.com/rust-lang/rfcs/pull/509 is accepted.
All of these collections have already been moved to collect-rs where they will ideally be maintained and experimented with, or will be replaced by something better: https://github.com/Gankro/collect-rs/
bors [Thu, 18 Dec 2014 20:32:07 +0000 (20:32 +0000)]
auto merge of #19896 : ktossell/rust/allow-nodoc-install, r=alexcrichton
If you configure with `--disable-docs`, the `doc` directory does not get generated, so the
`cp -r doc dist/` step fails when you `make dist{,-tar-bins,-doc}` or `make install`.
bors [Thu, 18 Dec 2014 14:42:06 +0000 (14:42 +0000)]
auto merge of #19819 : vadimcn/rust/fix-demangle, r=alexcrichton
Windows dbghelp strips leading underscores from symbols, and I could not find a way to turn this off. So let's accept "ZN...E" form too.
Also, print PC displacement from symbols. This is helpful in gauging whether the PC was indeed within the function displayed in the backtrace, or whether it just happened to be the closest public symbol in the module.
James Miller [Mon, 15 Dec 2014 23:21:08 +0000 (12:21 +1300)]
Only count nested returns when the outer return is reachable
This narrows the definition of nested returns such that only when the
outer return has a chance of being executed (due to the inner return
being conditional) do we mark the function as having nested returns.
Ken Tossell [Mon, 15 Dec 2014 22:40:43 +0000 (17:40 -0500)]
Only try to install the doc directory if it exists.
If you configure with `--disable-docs`, the `doc` directory does not get generated, so
`cp -r doc dist/` fails when you `make dist{,-tar-bins,-doc}` or `make install`
Alex Crichton [Wed, 17 Dec 2014 16:35:45 +0000 (08:35 -0800)]
rollup merge of #19930: cllns/lowercase-if
On the [guide site](http://doc.rust-lang.org/guide.html#if) I was confused when I got to "5 If". It looked like "5 LF" in lowercase.
Changing the if to lowercase solves this problem. I know titles are all capitalized, but I think it makes sense in this case to keep it lowercase, since `if` is a reserved word. I'd also be open to making it ``` `if` ``` but I'm not sure how that would look on the site.
Before:
![screen shot 2014-12-16 at 12 58 01](https://cloud.githubusercontent.com/assets/632942/5458866/cb34c006-8523-11e4-89ef-3a3964bcedfc.png)
After:
![screen shot 2014-12-16 at 12 58 14](https://cloud.githubusercontent.com/assets/632942/5458865/cb33c444-8523-11e4-8d95-d377ed583ed6.png)
Alex Crichton [Wed, 17 Dec 2014 16:35:26 +0000 (08:35 -0800)]
rollup merge of #19912: P1start/fn-formatting
This is to encourage the use of the sugary syntax instead of the `<>` syntax, which will not be usable post-1.0. Rustdoc [still uses the `<>` syntax](https://github.com/rust-lang/rust/issues/19909), so if a rustdoc wizard is looking for something to do, it would be nice to use the parenthetical syntax there as well. (I tried to patch rustdoc as well, but failed…)
Alex Crichton [Wed, 17 Dec 2014 16:35:23 +0000 (08:35 -0800)]
rollup merge of #19905: AaronFriel/patch-1
Was testing rustup on a very minimal Debian installation and got errors during the install process (error occurred in `install.sh` of the Rust nightly.)
Noticed that Rustup was downloading the i686 nightly instead of x86-64. Installing `file` fixed the problem, and this patch adds the probe to ensure file is installed before attempting to use it.
There may still be an issue with the i686 installation, I did not investigate further.
Alex Crichton [Wed, 17 Dec 2014 16:35:07 +0000 (08:35 -0800)]
rollup merge of #19892: pnkfelix/region-graphviz
Added -Z print-region-graph debugging option; produces graphviz visualization of region inference constraint graph.
Optionally uses environment variables `RUST_REGION_GRAPH=<path_template>` and `RUST_REGION_GRAPH_NODE=<node-id>` to select which file to output to and which AST node to print.
Alex Crichton [Wed, 17 Dec 2014 16:35:00 +0000 (08:35 -0800)]
rollup merge of #19887: alexcrichton/serialize-fn-mut
Relax some of the bounds on the decoder methods back to FnMut to help accomodate
some more flavorful variants of decoders which may need to run the closure more
than once when it, for example, attempts to find the first successful enum to
decode.
Alex Crichton [Wed, 17 Dec 2014 16:34:34 +0000 (08:34 -0800)]
rollup merge of #19859: alexcrichton/flaky-test
This test would read with a timeout and then send a UDP message, expecting the
message to be received. The receiving port, however, was bound in the child
thread so it could be the case that the timeout and send happens before the
child thread runs. To remedy this we just bind the port before the child thread
runs, moving it into the child later on.
* iter - now returns a struct called Iter
* iter_mut - now returns a struct called IterMut
* into_iter - now returns a struct called IntoIter, Clone is never implemented
This is a breaking change due to the modifications to the names of the iterator
types returned. Code referencing the old names should updated to referencing the
newer names instead. This is also a breaking change due to the fact that
`IntoIter` no longer implements the `Clone` trait.
These items were explicitly not stabilized
* as_slice - waiting on indexing conventions
* as_mut_slice - waiting on conventions with as_slice as well
* cloned - the API was still just recently added
* ok_or - API remains experimental
* ok_or_else - API remains experimental
Alex Crichton [Wed, 17 Dec 2014 16:34:03 +0000 (08:34 -0800)]
rollup merge of #19820: alexcrichton/deprecate-some-more-libs
This commit deprecates a few more in-tree libs for their crates.io counterparts.
Note that this commit does not make use of the #[deprecated] tag to prevent
warnings from being generated for in-tree usage. Once #[unstable] warnings are
turned on then all external users will be warned to move.
These crates have all been duplicated in rust-lang/$crate repositories so
development can happen independently of the in-tree copies. We can explore at a
later date replacing the in-tree copies with the external copies, but at this
time the libraries have changed very little over the past few months so it's
unlikely for changes to be sent to both repos.
Alex Crichton [Wed, 17 Dec 2014 16:34:01 +0000 (08:34 -0800)]
rollup merge of #19818: emk/regex_at_name_opt
Hello! This is my first Rust patch, and I fear that I've probably skipped at least 7 critical steps. I'd appreciate your feedback and advice about how to contribute to Rust.
This patch is based on a discussion with @BurntSushi in #14602 a while back. I'm happy to revise it as needed to fit into the modern world. :-)
As discussed in that issue, the existing `at` and `name` functions represent two different results with the empty string:
1. Matched the empty string.
2. Did not match anything.
Consider the following example. This regex has two named matched groups, `key` and `value`. `value` is optional:
```rust
// Matches "foo", "foo;v=bar" and "foo;v=".
regex!(r"(?P<key>[a-z]+)(;v=(?P<value>[a-z]*))?");
```
We can access `value` using `caps.name("value")`, but there's no way for us to distinguish between the `"foo"` and `"foo;v="` cases.
Early this year, @BurntSushi recommended modifying the existing `at` and `name` functions to return `Option`, instead of adding new functions to the API.
Alex Crichton [Wed, 17 Dec 2014 16:33:58 +0000 (08:33 -0800)]
rollup merge of #19770: csouth3/iterator-wrapperstructs
Using a type alias for iterator implementations is fragile since this exposes the implementation to users of the iterator, and any changes could break existing code.
This PR changes the iterators of `BTreeMap`, `BTreeSet`, `HashMap`, and `HashSet` to use proper new types, rather than type aliases. However, since it is fair-game to treat a type-alias as the aliased type, this is a:
Alex Crichton [Wed, 17 Dec 2014 16:33:53 +0000 (08:33 -0800)]
rollup merge of #19755: alexcrichton/rust-serialize
The primary focus of Rust's stability story at 1.0 is the standard library.
All other libraries distributed with the Rust compiler are planned to
be #[unstable] and therfore only accessible on the nightly channel of Rust. One
of the more widely used libraries today is libserialize, Rust's current solution
for encoding and decoding types.
The current libserialize library, however, has a number of drawbacks:
* The API is not ready to be stabilize as-is and we will likely not have enough
resources to stabilize the API for 1.0.
* The library is not necessarily the speediest implementations with alternatives
being developed out-of-tree (e.g. serde from erickt).
* It is not clear how the API of Encodable/Decodable can evolve over time while
maintaining backwards compatibility.
One of the major pros to the current libserialize, however, is
`deriving(Encodable, Decodable)` as short-hands for enabling serializing and
deserializing a type. This is unambiguously useful functionality, so we cannot
simply deprecate the in-tree libserialize in favor of an external crates.io
implementation.
For these reasons, this commit starts off a stability story for libserialize by
following these steps:
1. The deriving(Encodable, Decodable) modes will be deprecated in favor of a
renamed deriving(RustcEncodable, RustcDecodable).
2. The in-tree libserialize will be deprecated in favor of an external
rustc-serialize crate shipped on crates.io. The contents of the crate will be
the same for now (but they can evolve separately).
3. At 1.0 serialization will be performed through
deriving(RustcEncodable, RustcDecodable) and the rustc-serialize crate. The
expansions for each deriving mode will change from `::serialize::foo` to
`::rustc_serialize::foo`.
This story will require that the compiler freezes its implementation of
`RustcEncodable` deriving for all of time, but this should be a fairly minimal
maintenance burden. Otherwise the crate in crates.io must always maintain the
exact definition of its traits, but the implementation of json, for example, can
continue to evolve in the semver-sense.
The major goal for this stabilization effort is to pave the road for a new
official serialization crate which can replace the current one, solving many of
its downsides in the process. We are not assuming that this will exist for 1.0,
hence the above measures. Some possibilities for replacing libserialize include:
* If plugins have a stable API, then any crate can provide a custom `deriving`
mode (will require some compiler work). This means that any new serialization
crate can provide its own `deriving` with its own backing
implementation, entirely obsoleting the current libserialize and fully
replacing it.
* Erick is exploring the possibility of code generation via preprocessing Rust
source files in the near term until plugins are stable. This strategy would
provide the same ergonomic benefit that `deriving` does today in theory.
So, in summary, the current libserialize crate is being deprecated in favor of
the crates.io-based rustc-serialize crate where the `deriving` modes are
appropriately renamed. This opens up space for a later implementation of
serialization in a more official capacity while allowing alternative
implementations to be explored in the meantime.
Concretely speaking, this change adds support for the `RustcEncodable` and
`RustcDecodable` deriving modes. After a snapshot is made warnings will be
turned on for usage of `Encodable` and `Decodable` as well as deprecating the
in-tree libserialize crate to encurage users to use rustc-serialize instead.
Alex Crichton [Wed, 17 Dec 2014 16:33:44 +0000 (08:33 -0800)]
rollup merge of #19720: csouth3/vecmap-newtypes
Using a type alias for iterator implementations is fragile since this
exposes the implementation to users of the iterator, and any changes
could break existing code.
This commit changes the iterators of `VecMap` to use
proper new types, rather than type aliases. However, since it is
fair-game to treat a type-alias as the aliased type, this is a: