Uh oh!
There was an error while loading. Please reload this page.
Rollup of 8 pull requests - #59682
Closed
Centril wants to merge 38 commits into
Closed
Conversation
- libarena - librustc_allocator - librustc_borrowck - librustc_codegen_ssa - librustc_codegen_utils - librustc_driver - librustc_errors - librustc_incremental - librustc_metadata - librustc_passes - librustc_privacy - librustc_resolve - librustc_save_analysis - librustc_target - librustc_traits - libsyntax - libsyntax_ext - libsyntax_pos
- libfmt_macros - librustdoc
This commit removes usage of `Once` from the internal implementation of time utilities on OSX and Windows. It turns out that we accidentally hit a deadlock today (rust-lang#59020) via events that look like: * A thread invokes `park_timeout` * Internally, only on OSX, `park_timeout` calls `Instant::elapsed` * Inside of `Instant::elapsed` on OSX we enter a `Once` to initialize global timer data * Inside of `Once`, it attempts to `park` This means on the same stack frame, when there's contention, we're calling `park` from inside `park_timeout`, causing a deadlock! The solution implemented in this commit was to remove usage of `Once` and instead just do a small dance with atomics. There's no real need we need to guarantee that the global information is only learned once, only that it's only *stored* once. This implementation may have multiple threads invoke `mach_timebase_info`, but only one will store the global information which will amortize the cost for all other threads. A similar fix has been applied to windows to be uniform across our implementations, but looking at the code on Windows no deadlock was possible. This is purely just a consistency update for Windows and in theory a slightly leaner implementation. Closesrust-lang#59020
When using the `rustfix-coverage` flag, some tests currently fail because they define a different error-format than `json`. The current implementation crashes when encountering those tests. Since we don't care about non-json test output when collecting the coverage data, we handle those tests by returning an empty `Vec` instead.
…li-obk Internal lints take 2 cc rust-lang#58701 cc rust-lang#49509 TODO: Add `#![warn(internal)]` to crates (and fix violations) Crates depending on `rustc_data_structures` - [x] librustc_resolve - [x] librustc_driver - [x] librustc_passes - [x] librustc_metadata - [x] librustc_interface - [x] librustc_save_analysis - [x] librustc_lint - [x] librustc - [x] librustc_incremental - [x] librustc_codegen_utils - [x] libarena - [x] librustc_target - [x] librustc_allocator - [x] librustc_privacy - [x] librustc_traits - [x] librustc_borrowck - [x] libsyntax - [x] librustc_codegen_ssa - [x] libsyntax_ext - [x] librustc_errors - [x] librustc_mir - [x] libsyntax_pos - [x] librustc_typeck Crates with `feature(rustc_private)` Excluding crates, which are already in the list above. Also excluding tools and tests. - [ ] ~~libstd~~ - [x] libfmt_macros - [x] librustdoc r? @oli-obk
Be more direct about borrow contract
I always was confused by the difference between Borrow and AsRef, despite the fact that I've read all available docs at least a dozen of times.
I finally grokked the difference between the two when I realized the Borrow invariant:
> If you implement Borrow, you **must** make sure that Eq, Ord and Hash implementations are equivalent for borrowed and owned data
My problem was that this invariant is not stated explicitly in documentation, and instead some vague and philosophical notions are used.
So I suggest to mention the requirements of `Borrow` very explicitly: instead of "use Borrow when X and use AsRef when Y", let's phrase this as `Borrow` differs from `AsRef` in `W`, so that's why `Borrow` is for `X` and `AsRef` is for `Y`.
Note that this change could be seen as tightening contract of the Borrow. Let's say Alice has written the following code:
```rust
#[derive(PartialEq, Eq, Hash, PartialOrd, Ord)]
struct Person {
first_name: String,
last_name: String,
}
impl Borrow<str> for Person {
fn borrow(&self) -> &str { self.first_name.as_str() }
}
```
Now Bob uses this `Person` struct, puts it into `HashMap` and tries to look it up using `&str` for the first name. Bob's code naturally fails.
The question is, who is to blame: Alice, who has written the impl, or Bob, who uses the HashMap. If I read the current docs literally, I would say that `Bob` is to blame: `Eq` and `Hash` bounds appear on HashMap, so it is the HashMap which requires that they are consistent. By using a type for which the `Borrow` impl does not yield well-behaved `Eq`, Bob is violating contract of HashMap.
If, as this PR proposes, we unconditionally require that Eq & friends for borrow should be valid, then the blame shifts to Alice, which I think is more reasonable.
closesrust-lang#44868… r=alexcrichton Updated the documentation of spin_loop and spin_loop_hint # Description - Updated the description of `core::hints::spin_loop` - Updated the description of `core::async::spin_loop_hint` Both documentation is rewritten to better reflect when one should prefer using a busy-wait spin-loop (and the `spin_loop` and `spin_loop_hint` functions) over `yield_now`. It also dives a little bit deeper on what the function actually does. closesrust-lang#55418
…criptions, r=GuillaumeGomez Updated the environment description in rustc. # Description - Updated the "environment" description in the `rustc` man pages The old wording suggested that all the mentioned flags influenced the output of the compiler, where this was not the case. closesrust-lang#59504
Revert rust-lld place changes Fixesrust-lang#59661. Instead of rust-lang#59668 it reverts only failed part.
std: Avoid usage of `Once` in `Instant` This commit removes usage of `Once` from the internal implementation of time utilities on OSX and Windows. It turns out that we accidentally hit a deadlock today (rust-lang#59020) via events that look like: * A thread invokes `park_timeout` * Internally, only on OSX, `park_timeout` calls `Instant::elapsed` * Inside of `Instant::elapsed` on OSX we enter a `Once` to initialize global timer data * Inside of `Once`, it attempts to `park` This means on the same stack frame, when there's contention, we're calling `park` from inside `park_timeout`, causing a deadlock! The solution implemented in this commit was to remove usage of `Once` and instead just do a small dance with atomics. There's no real need we need to guarantee that the global information is only learned once, only that it's only *stored* once. This implementation may have multiple threads invoke `mach_timebase_info`, but only one will store the global information which will amortize the cost for all other threads. A similar fix has been applied to windows to be uniform across our implementations, but looking at the code on Windows no deadlock was possible. This is purely just a consistency update for Windows and in theory a slightly leaner implementation. Closesrust-lang#59020
…er_error_formats, r=oli-obk rustfix coverage: Skip UI tests with non-json error-format When using the `rustfix-coverage` flag, some tests currently fail because they define a different error-format than `json`. The current implementation crashes when encountering those tests. Since we don't care about non-json test output when collecting the coverage data, we handle those tests by returning an empty `Vec` instead. r? @oli-obk
Centril
commented
Apr 3, 2019
ContributorAuthor
@bors r+ p=8 |
bors
commented
Apr 3, 2019
Collaborator
📌 Commit f5f8547 has been approved by |
bors
commented
Apr 3, 2019
Collaborator
⌛ Testing commit f5f8547 with merge a18409138d0d079a7f44f4da37cf52ea6df1f546... |
rust-highfive
commented
Apr 3, 2019
Contributor
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
bors
commented
Apr 3, 2019
Collaborator
💔 Test failed - checks-travis |
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
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
8 participants
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.
Successful merges:
OnceinInstant#59676 (std: Avoid usage ofOnceinInstant)Failed merges:
r? @ghost