Rollup of 11 pull requests #40810
Closed
Rollup of 11 pull requests #40810
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
This alters the stdio code on Windows to always call `GetStdHandle` whenever the stdio read/write functions are called as this allows us to track changes to the value over time (such as if a process calls `SetStdHandle` while it's running). Closes rust-lang#40490
Now that we've also updated cargo's release process this commit also changes the download location of Cargo from Cargos archives back to the static.r-l.o archives. This should ensure that the Cargo download is the exact Cargo paired with the rustc that we release.
This "on-demand" task both checks for errors and computes the custom unsized kind, if any. This task is only defined on impls of `CoerceUnsized`; invoking it on any other kind of impl results in a bug. This is just to avoid having an `Option`, could easily be changed.
Top-down, top-down!
When the Range expression is the root of a constant, its node-id is used for the def-id of the body, so it has to be preserved in the AST -> HIR lowering. Fixes rust-lang#40749.
There are now 3 queries: - inherent_impls(def-id): for a given type, get a `Rc<Vec<DefId>>` with all its inherent impls. This internally uses `crate_inherent_impls`, doing some hacks to keep the current deps (which, btw, are not clearly correct). - crate_inherent_impls(crate): gathers up a map from types to `Rc<Vec<DefId>>`, touching the entire krate, possibly generating errors. - crate_inherent_impls_overlap_check(crate): performs overlap checks between the inherent impls for a given type, generating errors.
This commit deletes the internal liblog in favor of the implementation that
lives on crates.io. Similarly it's also setting a convention for adding crates
to the compiler. The main restriction right now is that we want compiler
implementation details to be unreachable from normal Rust code (e.g. requires a
feature), and by default everything in the sysroot is reachable via `extern
crate`.
The proposal here is to require that crates pulled in have these lines in their
`src/lib.rs`:
#![cfg_attr(rustbuild, feature(staged_api, rustc_private))]
#![cfg_attr(rustbuild, unstable(feature = "rustc_private", issue = "27812"))]
This'll mean that by default they're not using these attributes but when
compiled as part of the compiler they do a few things:
* Mark themselves as entirely unstable via the `staged_api` feature and the
`#![unstable]` attribute.
* Allow usage of other unstable crates via `feature(rustc_private)` which is
required if the crate relies on any other crates to compile (other than std).
I'm not really sure what we want the cadence here to be. We'll at the very least update the Cargo submodule right before all releases, but otherwise I figured we could just do it whenever needed or otherwise weekly (or something like that). In any case, I don't have a super strong particular reason to do this, it's just been a week or so since the release!
Prior to this commit, most of the `BufRead` examples used `StdinLock` to demonstrate how certain `BufRead` methods worked. Using `StdinLock` is not ideal since: * Relying on run-time data means we can't show concrete examples of how these methods work up-front. The user is required to run them in order to see how they behave. * If the user tries to run an example in the playpen, it won't work because the playpen doesn't support user input to stdin.
This change slightly changes the main iteration loop so that LLVM can optimize it more efficiently. Benchmark: name before ns/iter after ns/iter diff ns/iter diff % slice::sort_unstable_small_ascending 39 (2051 MB/s) 38 (2105 MB/s) -1 -2.56% slice::sort_unstable_small_big_random 579 (2210 MB/s) 575 (2226 MB/s) -4 -0.69% slice::sort_unstable_small_descending 80 (1000 MB/s) 70 (1142 MB/s) -10 -12.50% slice::sort_unstable_small_random 396 (202 MB/s) 386 -10 -2.53%
Looks like the last version was built with mio 0.6.5 which now has known bugs against it. This build includes mio 0.6.6
Remove internal liblog
This commit deletes the internal liblog in favor of the implementation that
lives on crates.io. Similarly it's also setting a convention for adding crates
to the compiler. The main restriction right now is that we want compiler
implementation details to be unreachable from normal Rust code (e.g. requires a
feature), and by default everything in the sysroot is reachable via `extern
crate`.
The proposal here is to require that crates pulled in have these lines in their
`src/lib.rs`:
#![cfg_attr(rustbuild, feature(staged_api, rustc_private))]
#![cfg_attr(rustbuild, unstable(feature = "rustc_private", issue = "27812"))]
This'll mean that by default they're not using these attributes but when
compiled as part of the compiler they do a few things:
* Mark themselves as entirely unstable via the `staged_api` feature and the
`#![unstable]` attribute.
* Allow usage of other unstable crates via `feature(rustc_private)` which is
required if the crate relies on any other crates to compile (other than std).
Allow `use` macro imports to shadow global macros
Terminology:
- global scope: builtin macros, macros from the prelude, `#[macro_use]`, or `#![plugin(..)]`.
- legacy scope: crate-local `macro_rules!`.
- modern scope: `use` macro imports, `macro` (once implemented).
Today, the legacy scope can shadow the global scope (modulo RFC 1560 expanded shadowing restrictions). However, the modern scope cannot shadow or be shadowed by either the global or legacy scopes, leading to ambiguity errors.
This PR allows the modern scope to shadow the global scope (subject to some restrictions).
More specifically, a name in the global scope is as shadowable as a glob import in the module `self`. In other words, we imagine a special, implicit glob import in each module item:
```rust
mod foo {
#[lexical_only] // Not accessible via `foo::<name>`, like pre-RFC 1560 `use` imports.
#[shadowable_by_legacy_scope] // for back-compat
use <global_macros>::*;
}
```
r? @nrc
…uron std: Don't cache stdio handles on Windows This alters the stdio code on Windows to always call `GetStdHandle` whenever the stdio read/write functions are called as this allows us to track changes to the value over time (such as if a process calls `SetStdHandle` while it's running). Closes rust-lang#40490
rustbuild: Update bootstrap compiler Now that we've also updated cargo's release process this commit also changes the download location of Cargo from Cargos archives back to the static.r-l.o archives. This should ensure that the Cargo download is the exact Cargo paired with the rustc that we release.
…ikomatsakis On-demandify the typechecking of item bodies r? @nikomatsakis
…=GuillaumeGomez Rewrite `io::BufRead` doc examples to better demonstrate behaviors. Prior to this commit, most of the `BufRead` examples used `StdinLock` to demonstrate how certain `BufRead` methods worked. Using `StdinLock` is not ideal since: * Relying on run-time data means we can't show concrete examples of how these methods work up-front. The user is required to run them in order to see how they behave. * If the user tries to run an example in the playpen, it won't work because the playpen doesn't support user input to stdin.
…ed-info, r=eddyb on-demand-ify `custom_coerce_unsized_kind` and `inherent-impls` This "on-demand" task both checks for errors and computes the custom unsized kind, if any. This task is only defined on impls of `CoerceUnsized`; invoking it on any other kind of impl results in a bug. This is just to avoid having an `Option`, could easily be changed. r? @eddyb
keep the AST node-id when lowering ExprKind::Range When the Range expression is the root of a constant, its node-id is used for the def-id of the body, so it has to be preserved in the AST -> HIR lowering. Fixes rust-lang#40749. r? @eddyb beta-nominating because regression
…ichton Update cargo submodule I'm not really sure what we want the cadence here to be. We'll at the very least update the Cargo submodule right before all releases, but otherwise I figured we could just do it whenever needed or otherwise weekly (or something like that). In any case, I don't have a super strong particular reason to do this, it's just been a week or so since the release!
…=alexcrichton Optimize insertion sort This change slightly changes the main iteration loop so that LLVM can optimize it more efficiently. Benchmark: ``` name before ns/iter after ns/iter diff ns/iter diff % slice::sort_unstable_small_ascending 39 (2051 MB/s) 38 (2105 MB/s) -1 -2.56% slice::sort_unstable_small_big_random 579 (2210 MB/s) 575 (2226 MB/s) -4 -0.69% slice::sort_unstable_small_descending 80 (1000 MB/s) 70 (1142 MB/s) -10 -12.50% slice::sort_unstable_small_random 396 (202 MB/s) 386 -10 -2.53% ``` The benchmark is not a fluke. I can see that performance on `small_descending` is consistently better after this change. I'm not 100% sure why this makes things faster, but my guess would be that `v.len()+1` to the compiler looks like it could in theory overflow.
…r=alexcrichton travis: Update sccache again Looks like the last version was built with mio 0.6.5 which now has known bugs against it. This build includes mio 0.6.6
|
r? @eddyb (rust_highfive has picked a reviewer for you, use r? to override) |
|
@bors: r+ p=10 |
|
📌 Commit 9dc591c has been approved by |
|
⌛ Testing commit 9dc591c with merge 97e7541... |
|
💔 Test failed - status-appveyor |
|
@bors: retry |
|
💔 Test failed - status-appveyor |
|
@bors: retry Let's see if that's spurious... |
|
⌛ Testing commit 9dc591c with merge 584bc98... |
|
💔 Test failed - status-travis |
|
@bors: retry
…On Mar 25, 2017 12:24 AM, "bors" ***@***.***> wrote:
💔 Test failed - status-travis
<https://travis-ci.org/rust-lang/rust/builds/214892700>
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#40810 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAD95EuysqEUbs5Z9AqCj0U5GblL31j3ks5rpKT9gaJpZM4Mo7eZ>
.
|
|
Previous failure is: |
|
💔 Test failed - status-travis |
|
Same failure: Cargo problem? |
|
☔ The latest upstream changes (presumably #40826) made this pull request unmergeable. Please resolve the merge conflicts. |
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.
usemacro imports to shadow global macros #40501, std: Don't cache stdio handles on Windows #40516, rustbuild: Update bootstrap compiler #40524, On-demandify the typechecking of item bodies #40540, Rewriteio::BufReaddoc examples to better demonstrate behaviors. #40642, on-demand-ifycustom_coerce_unsized_kindandinherent-impls#40683, keep the AST node-id when lowering ExprKind::Range #40764, Update cargo submodule #40778, Optimize insertion sort #40807, travis: Update sccache again #40809