Rolling up PRs in the queue #19958
Merged
Rolling up PRs in the queue #19958
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This will hopefully help people with their first steps in Rust. Fixes rust-lang#16143.
This is just a refactoring of the current installer so that Rust and Cargo use the same codebase. cc rust-lang#16456
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. cc rust-lang#19260
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: [breaking-change].
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.
Error message has wrong spelling ("radix is to high").
Closes rust-lang#14602. 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. This is a [breaking-change], but the fix is easy: - `refs.at(1)` becomes `refs.at(1).unwrap_or("")`. - `refs.name(name)` becomes `refs.name(name).unwrap_or("")`.
Both ContravariantLifetime and CovariantLifetime are marked as Copy, so it makes sense for InvariantLifetime to be as well.
This commit takes a second pass through the `std::option` module to fully stabilize any lingering methods inside of it. These items were made stable as-is * Some * None * as_mut * expect * unwrap * unwrap_or * unwrap_or_else * map * map_or * map_or_else * and_then * or_else * unwrap_or_default * Default implementation * FromIterator implementation * Copy implementation These items were made stable with modifications * 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 [breaking-change]
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. cc rust-lang#19120
In US english, "that" is used in restrictive clauses in place of "which", and often affects the meaning of sentences. In UK english and many dialects, no distinction is made. While Rust devs want to avoid unproductive pedanticism, it is worth at least being uniform in documentation such as: http://doc.rust-lang.org/std/iter/index.html and also in cases where correct usage of US english clarifies the sentence.
… trigger warnings
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. This a breaking change due to the bounds for the trait switching, and clients will need to update from `FnOnce` to `FnMut` as well as likely making the local function binding mutable in order to call the function. [breaking-change]
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. Note that in some cases of method AST's, the identification of AST node is based on the id for the *body* of the method; this is largely due to having the body node-id already available at the relevant point in the control-flow of rustc in its current incarnation. Ideally we would handle identifying AST's by name in addition to node-id, e.g. the same way that the pretty-printer supports path suffixes as well as node-ids for identifying subtrees to print.
The rendered form in http://doc.rust-lang.org/nightly/std/rand/struct.OsRng.html looks wrong.
Includes a fix for a small mistake in `fn insert` which is caught by test_insert for len=15, but not len=7. Part of rust-lang#18424 r? @gankro @csherratt @huonw
In US english, "that" is used in restrictive clauses in place of "which", and often affects the meaning of sentences. In UK english and many dialects, no distinction is made. While Rust devs want to avoid unproductive pedanticism, it is worth at least being uniform in documentation such as: http://doc.rust-lang.org/std/iter/index.html and also in cases where correct usage of US english clarifies the sentence.
Now they trigger warnings.
This changes the `escape_unicode` method on a `char` to use the new style of unicode escapes in the language. Closes rust-lang#19811 Closes rust-lang#19879
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.
The fix just checks if the bound is `Copy` and returns an `Err` if so. Closes: rust-lang#19817 @nikomatsakis r?
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.
FIxed the spelling of the word "specific".
This commit stabilizes the `mem` and `default` modules of std.
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.
Fixes some tuple indexing deprecation warnings. Didn't test. Don't see how it could fail unless I need to modify a makefile somewhere... r? @alexcrichton
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](rust-lang#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…)
…exprbox-an-option This is to allow us to migrate away from UnUniq in a followup commit, and thus unify the code paths related to all forms of `box`.
Fix `make TAGS.emacs`. @nikomatsakis has been complaining to me about this. (I had not noticed since I drive `ctags` with a separate script.) (Suitable for a rollup build.)
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:  After: 
Signed-off-by: Philipp Gesang <[email protected]>
Random improvements to the `std::vec` docs.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
(addendum from pnkfelix: This is a retry of a previous manual rollup PR #19931 )