Rollup of 10 pull requests #25874
Closed
Rollup of 10 pull requests #25874
Conversation
This file contains 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
Member
steveklabnik
commented
May 29, 2015
steveklabnik
commented
- Successful merges: Document #[repr] on non-C-like enums #25651, Add a missing space to the Glossary page of TRPL #25788, Improve Debug documentation #25830, Contributing guide should explain the issue tracker tags #25832, Improve docs for Vec::as_slice and as_mut_slice #25838, reference: floating-point types are machine types, not machine-dependent types #25854, TRPL: Fix Unescaped URL #25857, removed lonely closing parenthesis #25864, Corrected typo #25865, Update style guide with latest commits from rust-guidelines #25866
- Failed merges:
`core::cell::Cell<T>` and `core::cell::RefCell<T>` currently implement `PartialEq` when `T` does, and just defer to comparing `T` values. There is no reason the same shouldn’t apply to `Eq`. This enables `#[derive(Eq, PartialEq)]` on e.g. structs that have a `RefCell` field.
Currently, there are two conditional blocks that exist to check for "clang or gcc"
On line 866:
```
if [ -z "$CFG_ENABLE_CLANG" -a -z "$CFG_GCC" ]
then
err "either clang or gcc is required"
fi
```
and on line 1019:
```
if [ -z "$CC" -a -z "$CFG_ENABLE_CLANG" -a -z "$CFG_GCC" ]
then
err "either clang or gcc is required"
fi
```
Given the order of the clauses, this results in the "either clang or gcc is required" error from the earlier block, (even) when CC is set.
The expected behaviour is to honour user-flags, in this case CC.
Aside from removing all hand-holdy compiler checks in favour of actual compiler *feature* checks, this change removes the redundant former block in favour of the latter block, which appears designed to allow the expected behaviour.
Fixes rust-lang#23037. Fixes rust-lang#25339.
The changes scaled back in 4cc025d were a little too aggressive and broke a bunch of cross compilations by not defining the `LINK_$(1)` variable for all targets. This commit ensures that the variable is defined for all targets by defaulting it to the normal compiler if it's not already defined (it's only defined specially for MSVC). Closes rust-lang#25723
The output of individual tests can be captured now so it's safe to use colorized output even when running tests in parallel. Closes rust-lang#782.
Estimating August as the release date for 1.2.0.
rustc -C target-cpu=help is no longer supported. Recommend the llc tool intead like 'rustc --help'.
Windows tests can often deadlock if a child thread continues after the main thread and then panics, and a `println!` executed in a child thread after the main thread has exited is at risk of panicking.
The changes scaled back in 4cc025d were a little too aggressive and broke a bunch of cross compilations by not defining the `LINK_$(1)` variable for all targets. This commit ensures that the variable is defined for all targets by defaulting it to the normal compiler if it's not already defined (it's only defined specially for MSVC). Closes rust-lang#25723 Closes rust-lang#25802
Currently part of the description of the `into_inner` method of `UnsafeCell` seems backwards.
Currently, there are two conditional blocks that exist to check for "clang or gcc"
On line 866:
```
if [ -z "$CFG_ENABLE_CLANG" -a -z "$CFG_GCC" ]
then
err "either clang or gcc is required"
fi
```
and on line 1019:
```
if [ -z "$CC" -a -z "$CFG_ENABLE_CLANG" -a -z "$CFG_GCC" ]
then
err "either clang or gcc is required"
fi
```
Given the order of the clauses, this results in the "either clang or gcc is required" error from the earlier block, (even) when CC is set.
The expected behaviour is to honour user-flags, in this case CC.
Aside from removing all hand-holdy compiler checks in favour of actual compiler *feature* checks, this change removes the redundant former block in favour of the latter block, which appears designed to allow the expected behaviour.
Quick update to fix two manpage issues I noticed in rust-lang#25689.
- Successful merges: rust-lang#25128, rust-lang#25651, rust-lang#25668, rust-lang#25726, rust-lang#25760, rust-lang#25792, rust-lang#25806, rust-lang#25807 - Failed merges:
collections: Make BinaryHeap panic safe in sift_up / sift_down Use a struct called Hole that keeps track of an invalid location in the vector and fills the hole on drop. I include a run-pass test that the current BinaryHeap fails, and the new one passes. NOTE: The BinaryHeap will still be inconsistent after a comparison fails. It will not have the heap property. What we fix is just that elements will be valid values. This is actually a performance win -- the new code does not bother to write in `zeroed()` values in the holes, it just leaves them as they were. Net result is something like a 5% decrease in runtime for `BinaryHeap::from_vec`. This can be further improved by using unchecked indexing (I confirmed it makes a difference, not a surprise with the non-sequential access going on), but let's leave that for another PR. Safety first 😉 Fixes rust-lang#25842
There was no opening parenthesis for this closing parenthesis...
`core::cell::Cell<T>` and `core::cell::RefCell<T>` currently implement `PartialEq` when `T` does, and just defer to comparing `T` values. There is no reason the same shouldn’t apply to `Eq`. This enables `#[derive(Eq, PartialEq)]` on e.g. structs that have a `RefCell` field. r? @alexcrichton I’m unsure what to do with `#[stable]` attributes on `impl`s. `impl`s generated by `#[derive]` don’t have them.
"workd" corrected to "world"
The current version of hoedown treats lists interrupting paragraphs in the Markdown.pl style rather than CommonMark, so a newline is needed for the list to be rendered properly.
"Idiomatic code should not use extra whitespace in the middle of a line to provide alignment."
Document #[repr] on non-C-like enums
rustc accepts the following today:
#[repr(u8)]
enum Flag<T> {
Dropped,
Alive(T),
}
and it has a good use (it appears to me): this inhibits the non-nullable
pointer optimization that the regular Option<T> and similar enums allow.
Document this in the reference, and add tests to make sure it compiles.
This means that we guarantee with `repr` that the discriminant will be
present and with that size, but not sure if we want to guarantee
anything more (no guarantee on placement in struct).
…ossary, r=steveklabnik r? @steveklabnik
…lexcrichton I took a guess at what they mean, but could be totally wrong. Please comment, and I'll update the PR with corrections!
Thanks to @cers who reported this in killercup/trpl-ebook#14! r? @steveklabnik
There was no opening parenthesis for this closing parenthesis...
"workd" corrected to "world"
…abnik So that rust-guidelines can be deleted and src/doc/style can prosper as the official home of the rust guidelines. 😃
|
(rust_highfive has picked a reviewer for you, use r? to override) |
|
@bors: r+ p=1 |
|
📌 Commit 35d6491 has been approved by |
|
⌛ Testing commit 35d6491 with merge d3b78dc... |
|
💔 Test failed - auto-mac-32-opt |
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.