kennytm [Sat, 4 Aug 2018 06:35:53 +0000 (14:35 +0800)]
Rollup merge of #52995 - cramertj:smaller-await, r=withoutboats
Remove unnecessary local in await! generator
This makes `async { await!(future::ready(())) }` 4 bytes instead of 16. [Playground example](http://play.rust-lang.org/?gist=54c075599b9ff390fe505c75d6b98feb&version=nightly&mode=debug&edition=2018)
kennytm [Sat, 4 Aug 2018 06:35:51 +0000 (14:35 +0800)]
Rollup merge of #52969 - Keruspe:local_rebuild, r=alexcrichton
rustbuild: fix local_rebuild
If we detect a local rebuild (e.g. bootstrap compiler is the same version as target compiler), we set stage to 1.
When trying to build e.g. UnstableBook, we use Mode::ToolBootstrap and stage is 1.
Just allow Mode::ToolBootstrap and stagge != 0 if we are in a local_rebuild
This fixes building current master using current beta (as master hasn't yet been bumped to 1.30).
This should be backported to beta too, as currently we cannot build beta using itself because of that.
kennytm [Sat, 4 Aug 2018 06:35:50 +0000 (14:35 +0800)]
Rollup merge of #52968 - zackmdavis:app-lint-cability, r=estebank
App-lint-cability
@eminence recently pointed out (rust-lang/cargo#5846) that it's
surprising that `cargo fix` (now shipping with Cargo itself!) doesn't
fix very common lint warnings, which is as good of a reminder as any
that we should finish #50723.
(Previously, we did this on the librustc and libsyntax crates in #50724. I filed cmr/this-week-in-rust#685 in hopes of recruiting new contributors to do the rest.)
kennytm [Sat, 4 Aug 2018 06:35:49 +0000 (14:35 +0800)]
Rollup merge of #52940 - kennytm:move-checktool-protection-week, r=alexcrichton
Align 6-week cycle check with beta promotion instead of stable release.
The regression check is to make beta promotion easier, so it makes more
sense to use the Tuesday of the release week (T-2) as the end point of the
regression prevention, instead of Thursday (T-0). But since the beta
promotion PR is sent at Tuesday evening at UTC, the protection should
include the whole Tuesday as well, meaning the 6-week cycle will start from
Wednesdays.
This will also move the start of the regression protection week one day
earlier.
bors [Fri, 3 Aug 2018 12:22:17 +0000 (12:22 +0000)]
Auto merge of #52887 - yurydelendik:disable-lld-symbols, r=alexcrichton
Disable debug sections when optimization flags is set for LLD.
Currently LLD does not error when optimization is set and debugging information sections are present. (See discussion at https://reviews.llvm.org/D47901)
bors [Fri, 3 Aug 2018 06:34:16 +0000 (06:34 +0000)]
Auto merge of #52925 - RalfJung:sanity_check, r=oli-obk
check_const: use the same ParamEnv as codegen for statics
Fixes at least part of https://github.com/rust-lang/rust/issues/52849 (my CTFE-stress benchmark). Note that I do not know what I am doing here, this is just based on hints from @oli-obk.
* Bring in some fixes for `cargo fix`
* Update RLS/rustfmt to keep them compiling
* Update all tools to [depend on `rustc-workspace-hack`](https://github.com/rust-lang/rust/pull/52919#issuecomment-409802418)
* Change how we deal with feature unification amongst these builds.
bors [Fri, 3 Aug 2018 00:50:09 +0000 (00:50 +0000)]
Auto merge of #51657 - wesleywiser:wip_profiling, r=eddyb
Implement a self profiler
This is a work in progress implementation of #50780. I'd love feedback on the overall structure and code as well as some specific things:
- [The query categorization mechanism](https://github.com/rust-lang/rust/compare/master...wesleywiser:wip_profiling?expand=1#diff-19e0a69c10eff31eb2d16805e79f3437R101). This works but looks kind of ugly to me. Perhaps there's a better way?
- [The profiler assumes only one activity can run at a time](https://github.com/rust-lang/rust/compare/master...wesleywiser:wip_profiling?expand=1#diff-f8a403b2d88d873e4b27c097c614a236R177). This is obviously incompatible with the ongoing parallel queries.
- [The output code is just a bunch of `format!()`s](https://github.com/rust-lang/rust/compare/master...wesleywiser:wip_profiling?expand=1#diff-f8a403b2d88d873e4b27c097c614a236R91). Is there a better way to generate markdown or json in the compiler?
- [The query categorizations are likely wrong](https://github.com/rust-lang/rust/compare/master...wesleywiser:wip_profiling?expand=1#diff-19e0a69c10eff31eb2d16805e79f3437R101). I've marked what seemed obvious to me but I'm sure I got a lot of them wrong.
The overhead currently seems very low. Running `perf` on a sample compilation with profiling enabled reveals:
bors [Thu, 2 Aug 2018 21:39:14 +0000 (21:39 +0000)]
Auto merge of #52841 - petrochenkov:premacro, r=alexcrichton
resolve: Implement prelude search for macro paths, implement tool attributes
When identifier is macro path is resolved in scopes (i.e. the first path segment - `foo` in `foo::mac!()` or `foo!()`), scopes are searched in the same order as for non-macro paths - items in modules, extern prelude, tool prelude (see later), standard library prelude, language prelude, but with some extra shadowing restrictions (names from globs and macro expansions cannot shadow names from outer scopes). See the comment in `fn resolve_lexical_macro_path_segment` for more details.
"Tool prelude" currently contains two "tool modules" `rustfmt` and `clippy`, and is searched immediately after extern prelude.
This makes the [possible long-term solution](https://github.com/rust-lang/rfcs/blob/master/text/2103-tool-attributes.md#long-term-solution) for tool attributes exactly equivalent to the existing extern prelude scheme, except that `--extern=my_crate` making crate names available in scope is replaced with something like `--tool=my_tool` making tool names available in scope.
The `tool_attributes` feature is still unstable and `#![feature(tool_attributes)]` now implicitly enables `#![feature(use_extern_macros)]`. `use_extern_macros` is a prerequisite for `tool_attributes`, so their stabilization will happen in the same order.
If `use_extern_macros` is not enabled, then tool attributes are treated as custom attributes (this is temporary, anyway).
Fixes https://github.com/rust-lang/rust/issues/52576
Fixes https://github.com/rust-lang/rust/issues/52512
Fixes https://github.com/rust-lang/rust/issues/51277
cc https://github.com/rust-lang/rust/issues/52269
bors [Thu, 2 Aug 2018 19:42:19 +0000 (19:42 +0000)]
Auto merge of #52782 - pnkfelix:issue-45696-dangly-paths-for-box, r=eddyb
[NLL] Dangly paths for box
Special-case `Box` in `rustc_mir::borrow_check`.
Since we know dropping a box will not access any `&mut` or `&` references, it is safe to model its destructor as only touching the contents *owned* by the box.
----
There are three main things going on here:
1. The first main thing, this PR is fixing a bug in NLL where `rustc` previously would issue a diagnostic error in a case like this:
```rust
fn foo(x: Box<&mut i32>) -> &mut i32 { &mut **x }
```
such code was accepted by the AST-borrowck in the past, but NLL was rejecting it with the following message ([playground](https://play.rust-lang.org/?gist=13c5560f73bfb16d6dab3ceaad44c0f8&version=nightly&mode=release&edition=2015))
```
error[E0597]: `**x` does not live long enough
--> src/main.rs:3:40
|
3 | fn foo(x: Box<&mut i32>) -> &mut i32 { &mut **x }
| ^^^^^^^^ - `**x` dropped here while still borrowed
| |
| borrowed value does not live long enough
|
note: borrowed value must be valid for the anonymous lifetime #1 defined on the function body at 3:1...
--> src/main.rs:3:1
|
3 | fn foo(x: Box<&mut i32>) -> &mut i32 { &mut **x }
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
error: aborting due to previous error
```
2. The second main thing: The reason such code was previously rejected was because NLL (MIR-borrowck) incorporates a fix for issue #31567, where it models a destructor's execution as potentially accessing any borrows held by the thing being destructed. The tests with `Scribble` model this, showing that the compiler now catches such unsoundness.
However, that fix for issue #31567 is too strong, in that NLL (MIR-borrowck) includes `Box` as one of the types with a destructor that potentially accesses any borrows held by the box. This thus was the cause of the main remaining discrepancy between AST-borrowck and MIR-borrowck, as documented in issue #45696, specifically in [the last example of this comment](https://github.com/rust-lang/rust/issues/45696#issuecomment-345367873), which I have adapted into the `fn foo` shown above.
We did close issue #45696 back in December of 2017, but AFAICT that example was not fixed by PR #46268. (And we did not include a test, etc etc.)
This PR fixes that case, by trying to model the so-called `DerefPure` semantics of `Box<T>` when we traverse the type of the input to `visit_terminator_drop`.
3. The third main thing is that during a review of the first draft of this PR, @matthewjasper pointed out that the new traversal of `Box<T>` could cause the compiler to infinite loop. I have adjusted the PR to avoid this (by tracking what types we have previously seen), and added a much needed test of this somewhat odd scenario. (Its an odd scenario because the particular case only arises for things like `struct A(Box<A>);`, something which cannot be constructed in practice.)
bors [Thu, 2 Aug 2018 10:28:42 +0000 (10:28 +0000)]
Auto merge of #52906 - RalfJung:jemalloc, r=alexcrichton
enable jemalloc assertions when configured to do so
This is essentially a re-submission of the functional part of https://github.com/rust-lang/rust/pull/43648. I was unable to reproduce the issue I had back then, maybe something changed somewhere to no longer trigger the assertion.
bors [Thu, 2 Aug 2018 08:24:14 +0000 (08:24 +0000)]
Auto merge of #52890 - djrenren:test-visibility, r=petrochenkov
Reexport tests without polluting namespaces
This should fix issue #52557.
Basically now we gensym a new name for the test function and reexport that.
That way the test function's reexport name can't conflict because it was impossible for the test author to write it down.
We then use a `use` statement to expose the original name using the original visibility.
If we detect a local rebuild (e.g. bootstrap compiler is the same version as target compiler), we set stage to 1.
When trying to build e.g. UnstableBook, we use Mode::ToolBootstrap and stage is 1.
Just allow Mode::ToolBootstrap and stagge != 0 if we are in a local_rebuild
Zack M. Davis [Thu, 2 Aug 2018 03:30:04 +0000 (20:30 -0700)]
`Applicability`-ify librustc_lint
Andrew Chin recently pointed out (rust-lang/cargo#5846) that it's
surprising that `cargo fix` (now shipping with Cargo itself!) doesn't
fix very common lint warnings, which is as good of a reminder as any
that we should finish #50723.
bors [Thu, 2 Aug 2018 04:22:23 +0000 (04:22 +0000)]
Auto merge of #52847 - upsuper:thread-stack-reserve, r=alexcrichton
Don't commit thread stack on Windows
On Windows, there is a system level resource limitation called commit limit, which is roughly the sum of physical memory + paging files[1]. `CreateThread` by default commits the stack size[2], which unnecessarily takes such resource from the shared limit.
This PR changes it to only reserve the stack size rather than commit it. Reserved memory would only take the address space of the current process until it's actually accessed.
This should make the behavior on Windows match other platforms, and is also a pretty standard practice on Windows nowadays.
bors [Thu, 2 Aug 2018 00:14:21 +0000 (00:14 +0000)]
Auto merge of #52206 - RalfJung:zst-slices, r=alexcrichton
slices: fix ZST slice iterators making up pointers; debug_assert alignment in from_raw_parts
This fixes the problem that we are fabricating pointers out of thin air. I also managed to share more code between the mutable and shared iterators, while reducing the amount of macros.
I am not sure how useful it really is to add a `debug_assert!` in libcore. Everybody gets a release version of that anyway, right? Is there at least a CI job that runs the test suite with a debug version?
bors [Wed, 1 Aug 2018 19:54:06 +0000 (19:54 +0000)]
Auto merge of #52958 - pietroalbini:rollup, r=pietroalbini
Rollup of 15 pull requests
Successful merges:
- #52793 (Add test for NLL: unexpected "free region `` does not outlive" error )
- #52799 (Use BitVector for global sets of AttrId)
- #52809 (Add test for unexpected region for local data ReStatic)
- #52834 ([NLL] Allow conflicting borrows of promoted length zero arrays)
- #52835 (Fix Alias intra doc ICE)
- #52854 (fix memrchr in miri)
- #52899 (tests/ui: Add missing mips{64} ignores)
- #52908 (Use SetLenOnDrop in Vec::truncate())
- #52915 (Don't count MIR locals as borrowed after StorageDead when finding locals live across a yield terminator)
- #52926 (rustc: Trim down the `rust_2018_idioms` lint group)
- #52930 (rustc_resolve: record single-segment extern crate import resolutions.)
- #52939 (Make io::Read::read_to_end consider io::Take::limit)
- #52942 (Another SmallVec.extend optimization)
- #52947 (1.27 actually added the `armv5te-unknown-linux-musleabi` target)
- #52954 (async can begin expressions)
Pietro Albini [Wed, 1 Aug 2018 19:46:39 +0000 (21:46 +0200)]
Rollup merge of #52947 - Susurrus:patch-1, r=alexcrichton
1.27 actually added the `armv5te-unknown-linux-musleabi` target
The PR title says `armv5te-unknown-linux-musl`, but it looks like the final code merge renamed the target to `armv5te-unknown-linux-musleabi`. `rustup` reports this as correct as well.
The [Rust Platform Support](https://forge.rust-lang.org/platform-support.html) page needs this added as well, but I'm not certain what codebase that is generated from.
Pietro Albini [Wed, 1 Aug 2018 19:46:36 +0000 (21:46 +0200)]
Rollup merge of #52939 - ljedrz:fix_51746, r=kennytm
Make io::Read::read_to_end consider io::Take::limit
Add a custom implementation of `io::Read::read_to_end` for `io::Take` that doesn't reserve the default 32 bytes but rather `Take::limit` if `Take::limit < 32`.
It's a conservative adjustment that preserves the default behavior for `Take::limit >= 32`.
Pietro Albini [Wed, 1 Aug 2018 19:46:33 +0000 (21:46 +0200)]
Rollup merge of #52926 - alexcrichton:trim-idioms-lints, r=oli-obk
rustc: Trim down the `rust_2018_idioms` lint group
These migration lints aren't all up to par in terms of a good migration
experience. Some, like `unreachable_pub`, hit bugs like #52665 and unprepared
macros to be handled enough of the time. Others like linting against
`#[macro_use]` are swimming upstream in an ecosystem that's not quite ready (and
slightly buggy pending a few current PRs).
The general idea is that we will continue to recommend the `rust_2018_idioms`
lint group as part of the transition guide (as an optional step) but we'll be
much more selective about which lints make it into this group. Only those with a
strong track record of not causing too much churn will make the cut.
For calling `truncate` with non-zero lengths on non-`Drop` types, it seems that a redundant load and comparison gets replaced with an awkward sequence with a conditional move. In the unknown length case, the new code is no longer awkward.
Maybe someone moderately proficient at assembly could tell if this looks like a win or not.
---
This came up when discussing replacing `unsafe { vec.set_len(0) }` with `vec.clear()` in a project where the author was worried about potential performance degradation. It might be worth replacing some unsafe code, even it it's trivial to see that it's actually safe.
Pietro Albini [Wed, 1 Aug 2018 19:46:28 +0000 (21:46 +0200)]
Rollup merge of #52854 - RalfJung:memrchr, r=Kimundi
fix memrchr in miri
The previous PR https://github.com/rust-lang/rust/pull/52744 was not enough because it assumed that the split between the `mid` and `end` parts returned by `align_to` was aligned. But really the only guarantee we have is that the `mid` part is aligned, so make use of that.
Pietro Albini [Wed, 1 Aug 2018 19:46:26 +0000 (21:46 +0200)]
Rollup merge of #52834 - matthewjasper:allow-zst-conflicts, r=pnkfelix
[NLL] Allow conflicting borrows of promoted length zero arrays
This is currently overkill as there's no way to create two conflicting borrows of any promoted.
It is possible that the following code might not fail due to const eval in the future (@oli-obk?). In which case either the array marked needs to not be promoted, or to be checked for conflicts
```rust
static mut A: () = {
let mut y = None;
let z;
let mut done_y = false;
loop {
let x = &mut [1]; // < this array
if done_y {
z = x;
break;
}
y = Some(x);
done_y = true;
}
some_const_fn(y, z); // some_const_fn expects that y to not alias z.
};
```
bors [Wed, 1 Aug 2018 17:44:25 +0000 (17:44 +0000)]
Auto merge of #51609 - dscorbett:is_numeric, r=alexcrichton
Treat gc=No characters as numeric
[`char::is_numeric`](https://doc.rust-lang.org/std/primitive.char.html#method.is_numeric) and [`char::is_alphanumeric`](https://doc.rust-lang.org/std/primitive.char.html#method.is_alphanumeric) are documented to be defined “in terms of the Unicode General Categories 'Nd', 'Nl', 'No'”, but unicode.py does not group 'No' with the other 'N' categories. These functions therefore currently return `false` for characters like ⟨¾⟩ and ⟨①⟩.
Expand long-live-borrows-in-boxes test to include simplier illustrative cases.
After talking about the PR with eddyb, I decided it was best to try to
have some test cases that simplify the problem down to its core, so
that people trying to understand what the issue is here will see those
core examples first.
(Presumably the place that borrow_check ends up reporting for the
error about is no longer the root `Local` itself, and thus the note
diagnostic here stops firing.)
Since we know dropping a box will not access any `&mut` or `&`
references, it is safe to model its destructor as only touching the
contents *owned* by the box.
Note: At some point we may want to generalize this machinery to other
reference and collection types that are "pure" in the same sense as
box. If we add a `&move` reference type, it would probably also fall
into this branch of code. But for the short term, we will be
conservative and restrict this change to `Box<T>` alone.
The code works by recursively descending a deref of the `Box`. We
prevent `visit_terminator_drop` infinite-loop (which can arise in a
very obscure scenario) via a linked-list of seen types.
Note: A similar style stack-only linked-list definition can be found
in `rustc_mir::borrow_check::places_conflict`. It might be good at
some point in the future to unify the two types and put the resulting
definition into `librustc_data_structures/`.
----
One final note: Review feedback led to significant simplification of
logic here.
During review, eddyb RalfJung and I uncovered the heart of why I
needed a so-called "step 2" aka the Shallow Write to the Deref of the
box. It was because the `visit_terminator_drop`, in its base case,
will not emit any write at all (shallow or deep) to a place unless
that place has a need_drop.
So I was encoding a Shallow Write by hand for a `Box<T>`, as a
separate step from recursively descending through `*a_box` (which was
at the time known as "step 1"; it is now the *only* step, apart from
the change to the base case for `visit_terminator_drop` that this
commit now has encoded).
eddyb aruged that *something* should be emitting some sort of write in
the base case here (even a shallow one), of the dropped place, since
by analogy we also emit a write when you *move* a place. That led
to the revision here in this commit.
* (Its possible that this desired write should be attached in some
manner to StorageDead instead of Drop. But in this PR, I tried to
leave the StorageDead logic alone and focus my attention solely on
how Drop(x) is modelled in MIR-borrowck.)
Bryant Mairs [Wed, 1 Aug 2018 15:24:18 +0000 (08:24 -0700)]
1.27 actually added the `armv5te-unknown-linux-musleabi` target
The PR title says `armv5te-unknown-linux-musl`, but it looks like the final code merge renamed the target to `armv5te-unknown-linux-musleabi`. `rustup` reports this as correct as well.
The [Rust Platform Support](https://forge.rust-lang.org/platform-support.html) page needs this added as well, but I'm not certain what codebase that is generated from.
Alex Crichton [Tue, 31 Jul 2018 22:45:11 +0000 (15:45 -0700)]
rustc: Trim down the `rust_2018_idioms` lint group
These migration lints aren't all up to par in terms of a good migration
experience. Some, like `unreachable_pub`, hit bugs like #52665 and unprepared
macros to be handled enough of the time. Others like linting against
`#[macro_use]` are swimming upstream in an ecosystem that's not quite ready (and
slightly buggy pending a few current PRs).
The general idea is that we will continue to recommend the `rust_2018_idioms`
lint group as part of the transition guide (as an optional step) but we'll be
much more selective about which lints make it into this group. Only those with a
strong track record of not causing too much churn will make the cut.
projects / rust.git / log