-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 13 pull requests #32759
Rollup of 13 pull requests #32759
Conversation
(1) `x` can be used in main() after the call to spawn(). Because the variables follow normal move semantics, though the keyword `move` is used, and i32 implements `Copy`. (2) I remove this sentence because the previous sentence gives the referrence to `move closures`, and more description of `move` may be redundant.
Starting with the 1.10.0 release we would like to bootstrap all compilers from the previous stable release. For example the 1.10.0 compiler should bootstrap from the literal 1.9.0 release artifacts. To do this, however, we need a way to enable unstable features temporarily in a stable compiler (as the released compiler is stable), but it turns out we already have a way to do that! At compile time the configure script selects a `CFG_BOOTSTRAP_KEY` variable value and then exports it into the makefiles. If the `RUSTC_BOOTSTRAP_KEY` environment variable is set to this value, then the compiler is allowed to "cheat" and use unstable features. This method of choosing the bootstrap key, however, is problematic for the intention of bootstrapping from the previous release. Each time a 1.9.0 compiler is created, a new bootstrap key will be selected. That means that the 1.10.0 compiler will only compile from *our* literal release artifacts. Instead distributions would like to bootstrap from their own compilers, so instead we simply hardcode the bootstrap key for each release. This patch uses the same `CFG_FILENAME_EXTRA` value (a hash of the release string) as the bootstrap key. Consequently all 1.9.0 compilers, no matter where they are compiled, will have the same bootstrap key. Additionally we won't need to keep updating this as it'll be based on the release number anyway. Once the 1.9.0 beta has been created, we can update the 1.10.0 nightly sources (the `master` branch at that time) to bootstrap from that release using this hard-coded bootstrap key. We will likely just hardcode into the makefiles what the previous bootstrap key was and we'll change that whenever the stage0 compiler is updated.
We need to supply sext/zext attributes to LLVM to ensure that arguments are extended to the appropriate width in the correct way. Most platforms extend integers less than 32 bits, though not all.
Conflicts: src/doc/book/concurrency.md
The fixed issue that allowed this was rust-lang#12808.
The initial implementation of specialization did not use the `fast_reject` mechanism when checking for overlap, which caused a serious performance regression in some cases. This commit modifies the specialization graph to use simplified types for fast rejection when possible, and along the way refactors the logic for building the specialization graph. Closes rust-lang#32499
1. In the English/Japanese phrases example in the "Multiple File Crates" section of the "Crates and Modules" chapter, there are a total of 8 module files that Rust looks for, while only four were listed. This commit lists all 8 explicitly. 2. Title case fix.
r? @Aatch (rust_highfive has picked a reviewer for you, use r? to override) |
@bors r+ p=20 |
📌 Commit 9b40635 has been approved by |
⌛ Testing commit 9b40635 with merge 36622ee... |
💔 Test failed - auto-win-msvc-64-opt-rustbuild |
doc: there is no case that is shown, so something was likely missing … …from the change
…abnik Mention that it's not actually a data race The example can't cause a data race since different indices are accesed. (perhaps we should use an example where i iterates twice?) r? @steveklabnik
Minor doc fixes in "Crates and Modules" and "Lifetimes" chapters These commits fix a couple of (minor) issues in the _Crates and Modules_ and the _Lifetimes_ chapters of the book. r? @steveklabnik
@bors r+ force |
📌 Commit 8044c4b has been approved by |
⌛ Testing commit 8044c4b with merge 21d127b... |
💔 Test failed - auto-linux-64-opt-mir |
…lexcrichton Address FIXMEs related to short lifetimes in `HashMap`. None
Remove error description of `move` (1) `x` can be used in main() after the call to spawn(). Because the variables follow normal move semantics, though the keyword `move` is used, and i32 implements `Copy`. (2) I remove this sentence because the previous sentence gives the referrence to `move closures`, and more description of `move` may be redundant.
…=brson mk: Hardcode the bootstrap key for each release Starting with the 1.10.0 release we would like to bootstrap all compilers from the previous stable release. For example the 1.10.0 compiler should bootstrap from the literal 1.9.0 release artifacts. To do this, however, we need a way to enable unstable features temporarily in a stable compiler (as the released compiler is stable), but it turns out we already have a way to do that! At compile time the configure script selects a `CFG_BOOTSTRAP_KEY` variable value and then exports it into the makefiles. If the `RUSTC_BOOTSTRAP_KEY` environment variable is set to this value, then the compiler is allowed to "cheat" and use unstable features. This method of choosing the bootstrap key, however, is problematic for the intention of bootstrapping from the previous release. Each time a 1.9.0 compiler is created, a new bootstrap key will be selected. That means that the 1.10.0 compiler will only compile from *our* literal release artifacts. Instead distributions would like to bootstrap from their own compilers, so instead we simply hardcode the bootstrap key for each release. This patch uses the same `CFG_FILENAME_EXTRA` value (a hash of the release string) as the bootstrap key. Consequently all 1.9.0 compilers, no matter where they are compiled, will have the same bootstrap key. Additionally we won't need to keep updating this as it'll be based on the release number anyway. Once the 1.9.0 beta has been created, we can update the 1.10.0 nightly sources (the `master` branch at that time) to bootstrap from that release using this hard-coded bootstrap key. We will likely just hardcode into the makefiles what the previous bootstrap key was and we'll change that whenever the stage0 compiler is updated.
Handle integer-extending for C ABI We need to supply sext/zext attributes to LLVM to ensure that arguments are extended to the appropriate width in the correct way. Most platforms extend integers less than 32 bits, though not all.
Remove strange names created by lack of privacy-conscious name lookup The fixed issue that allowed this was rust-lang#12808.
Fix infinite loop in Arc::downgrade
Reinstate fast_reject for overlap checking The initial implementation of specialization did not use the `fast_reject` mechanism when checking for overlap, which caused a serious performance regression in some cases. This commit modifies the specialization graph to use simplified types for fast rejection when possible, and along the way refactors the logic for building the specialization graph. Closes rust-lang#32499 r? @nikomatsakis
Fix typos in atomic compare_exchange. Failure ordering can't be Release, not (not) Acquire. Seems like a typo copy-pasted all over.
@bors r+ force |
📌 Commit ee55501 has been approved by |
@bors force |
@bors force retry |
⌛ Testing commit ee55501 with merge 6409dfe... |
💔 Test failed - auto-mac-32-opt |
Travis seems to think tidy is fine but buildbot doesn't?
looks like some leftover files? |
HashMap
. #32668, Remove error description ofmove
#32679, Specialize equality for [T] and comparison for [u8] to use memcmp when possible #32699, mk: Hardcode the bootstrap key for each release #32731, Handle integer-extending for C ABI #32732, Remove strange names created by lack of privacy-conscious name lookup #32741, Fix infinite loop in Arc::downgrade #32745, Reinstate fast_reject for overlap checking #32748, Fix typos in atomic compare_exchange. #32757