Rollup #19931
Closed
Rollup #19931
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
Fix a panic where the compiler was looking at stale or old metadata. See rust-lang#19798, rust-lang#19772, rust-lang#19757, rust-lang#19744, rust-lang#19718, rust-lang#19691.
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]
- Change long inline code to code block - Replace double-hyphens with en dash - Miscellaneous rephrasings for clarity
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]
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 keys and values iterators of `BTreeMap` 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].
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 `BTreeSet` 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].
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 keys and values iterators of `HashMap` 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].
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 `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: [breaking-change].
Normalize late-bound regions in bare functions, stack closures, and traits and include them in the generated hash. Closes rust-lang#19791
Normalize late-bound regions in bare functions, stack closures, and traits and include them in the generated hash. Closes rust-lang#19791 r? @nikomatsakis (does my normalization make sense?) cc @alexcrichton
Error message has wrong spelling ("radix is to high").
Both ContravariantLifetime and CovariantLifetime are marked as Copy, so it makes sense for InvariantLifetime to be as well.
…hip-guide For reference, this is what the code example looks like before the change: 
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]
- Change long inline code to code block - Replace double-hyphens with en dash - Miscellaneous rephrasings for clarity **Edit**: Trivial `commit --amend` to change the commit message slightly.
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
Necessary to implement `Copy` on structs like this one:
``` rust
struct Slice<'a, T> {
_contravariant: marker::ContravariantLifetime<'a>,
_nosend: marker::NoSend,
data: *const T,
length: uint,
}
```
r? @alexcrichton
The rendered form in http://doc.rust-lang.org/nightly/std/rand/struct.OsRng.html looks wrong.
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.
FIxed the spelling of the word "specific".
This commit stabilizes the `mem` and `default` modules of std.
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
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.)
|
Still testing. |
bors
added a commit
that referenced
this pull request
Dec 16, 2014
| For a full description see [the logging crate][1]. | ||
| debugging linking in the compiler, you might set the following: | ||
|
|
||
| RUST_LOG=rustc::metadata::creader,rustc::util::filesearch,rustc::back::rpath |
There was a problem hiding this comment.
Rollup vommited on this line. I think it thinks it's Rust code. Need a text marker or something.
There was a problem hiding this comment.
Source PR has been fixed. Thanks @csouth3!
There was a problem hiding this comment.
My bad! I didn't think the code block would be parsed as Rust code when formatted like that.
There was a problem hiding this comment.
No worries, we all mess up. :)
There was a problem hiding this comment.
Just so that I can prevent issues like this in the future, should I be running make check after altering documentation rather than just using make docs? I was testing changes using make docs which I guess is the reason the problem snuck through in the first place.
There was a problem hiding this comment.
make check-docs will do it! :)
Edit: The above command tests all code examples in documentation, which the offending line was considered to be. Running it should turn up any errors of this nature.
There was a problem hiding this comment.
protips from @steveklabnik: you can run rustdoc on the area of interest, too.
There was a problem hiding this comment.
Gotcha, I must have missed that when reading through the Makefile. Thanks!
|
Trying again in #19958 |
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.
No description provided.