Corey Farwell [Tue, 13 Jun 2017 21:15:02 +0000 (17:15 -0400)]
Rollup merge of #42597 - mark-buer:park_timeout_example_fix, r=alexcrichton
Capture elapsed duration in Thread::park_timeout example
`beginning_park.elapsed()` might return a larger value within the loop as compared to that checked in the loop conditional.
Since `Duration` arithmetic is checked, hitting such an edge case will cause a panic.
Corey Farwell [Tue, 13 Jun 2017 21:15:00 +0000 (17:15 -0400)]
Rollup merge of #42496 - Razaekel:feature/integer_max-min, r=BurntSushi
Add max and min to Ord
Pursuant to issue #25663, this PR adds max and min methods with default implementations to std::cmp::Ord. It also modifies std::cmp::max|min to internally alias to Ord::max|min, so that any overrides of the default implementations are automatically used by std::cmp::max|min.
1. The first makes `str::index` just call `SliceIndex<str>::index`. It's intended to have no behavior change, except where the two methods were inconsistent.
2. The second actually adds the overflow checking to `get(_mut)` (and tests for it)
bors [Mon, 12 Jun 2017 11:39:35 +0000 (11:39 +0000)]
Auto merge of #42537 - michaelwoerister:tcx-for-dep-node, r=nikomatsakis
incr.comp.: Make DepNode `Copy` and valid across compilation sessions
This PR moves `DepNode` to a representation that does not need retracing and thus simplifies comparing dep-graphs from different compilation sessions. The code also gets a lot simpler in many places, since we don't need the generic parameter on `DepNode` anymore. See https://github.com/rust-lang/rust/issues/42294 for details.
~~NOTE: Only the last commit of this is new, the rest is already reviewed in https://github.com/rust-lang/rust/pull/42504.~~
This PR is almost done but there are some things I still want to do:
- [x] Add some module-level documentation to `dep_node.rs`, explaining especially what the `define_dep_nodes!()` macro is about.
- [x] Do another pass over the dep-graph loading logic. I suspect that we can get rid of building the `edges` map and also use arrays instead of hash maps in some places.
bors [Mon, 12 Jun 2017 04:08:14 +0000 (04:08 +0000)]
Auto merge of #42419 - ucarion:ucarion-explain-rc-arc-abbrev, r=frewsxcv
Explicate what "Rc" and "Arc" stand for.
A person on the weekly "Easy Questions" Reddit thread [was mystified by what `Arc`/`Rc` means](https://www.reddit.com/r/rust/comments/6dyud9/hey_rustaceans_got_an_easy_question_ask_here/did87ds/). Though this is explained in various places, it's not mentioned in the documentation directly.
This PR adds an explanation of the `Rc`/`Arc` acronyms to their respective documentations. There are two things I'm not sure of:
* Does "Rc" mean "Reference Count**er**" or "Reference Count**ed**"? ~~I went with the former.~~ *Edit:* I've changed this to use the latter alternative.
* Should this information be spelled out elsewhere, such as in the docs for the `rc` module?
bors [Sun, 11 Jun 2017 18:56:27 +0000 (18:56 +0000)]
Auto merge of #42155 - seanmonstar:unimplemented, r=sfackler
core: allow messages in unimplemented!() macro
This makes `unimplemented!()` match `unreachable!()`, allowing a message and possible formatting to be provided to better explain what and/or why something is not implemented.
I've used this myself in hyper for a while, include the type and method name, to better help while prototyping new modules, like `unimplemented!("Conn::poll_complete")`, or `unimplemented!("Conn::poll; state={:?}", state)`.
bors [Sun, 11 Jun 2017 16:40:52 +0000 (16:40 +0000)]
Auto merge of #40454 - djzin:fast-swap, r=sfackler
speed up mem::swap
I would have thought that the mem::swap code didn't need an intermediate variable precisely because the pointers are guaranteed never to alias. And.. it doesn't! It seems that llvm will also auto-vectorize this case for large structs, but alas it doesn't seem to have all the aliasing info it needs and so will add redundant checks (and even not bother with autovectorizing for small types). Looks like a lot of performance could still be gained here, so this might be a good test case for future optimizer improvements.
Here are the current benchmarks for the simd version of mem::swap; the timings are in cycles (code below) measured with 10 iterations. The timings for sizes > 32 which are not a multiple of 8 tend to be ever so slightly faster in the old code, but not always. For large struct sizes (> 1024) the new code shows a marked improvement.
\* = latest commit
† = subtracted from other measurements
bors [Sat, 10 Jun 2017 19:21:24 +0000 (19:21 +0000)]
Auto merge of #42563 - eddyb:infer, r=nikomatsakis
Disentangle InferCtxt, MemCategorizationContext and ExprUseVisitor.
At some point in the past, `InferCtxt` started being used to replace an old "`Typer`" abstraction, which provided access to `TypeckTables` and had optionally type inference to account for.
That didn't play so nicely with the `'gcx`/`'tcx` split and I had to introduce `borrowck_fake_infer_ctxt`.
The situation wasn't great but it wasn't too painful inside `rustc` itself.
Recently I've found that method being used in clippy, which does need EUV (before we make it plausible to run lints on HAIR or MIR), and set out to separate inference from tables, for the sake of lint authors.
Also fixes #42435 to make it trivial to compute type layout or use EUV from lints.
The remaining uses of `TypeckTables` in `InferCtxt` are for closure kinds and signatures, used in trait selection and projection normalization. The solution there is likely to add them as bounds to `ParamEnv`.
bors [Sat, 10 Jun 2017 09:11:36 +0000 (09:11 +0000)]
Auto merge of #42556 - scottmcm:ctz-nz, r=BurntSushi
Get LLVM to stop generating dead assembly in next_power_of_two
It turns out that LLVM can turn `@llvm.ctlz.i64(_, true)` into `@llvm.ctlz.i64(_, false)` ([`ctlz`](http://llvm.org/docs/LangRef.html#llvm-ctlz-intrinsic)) where valuable, but never does the opposite. That leads to some silly assembly getting generated in certain cases.
A contrived-but-clear example https://is.gd/VAIKuC:
```rust
fn foo(x:u64) -> u32 {
if x == 0 { return !0; }
x.leading_zeros()
}
```
Generates
```asm
testq %rdi, %rdi
je .LBB0_1
je .LBB0_3 ; <-- wha?
bsrq %rdi, %rax
xorq $63, %rax
retq
.LBB0_1:
movl $-1, %eax
retq
.LBB0_3:
movl $64, %eax ; <-- dead
retq
```
I noticed this in `next_power_of_two`, which without this PR generates the following:
```asm
cmpq $2, %rcx
jae .LBB1_2
movl $1, %eax
retq
.LBB1_2:
decq %rcx
je .LBB1_3
bsrq %rcx, %rcx
xorq $63, %rcx
jmp .LBB1_5
.LBB1_3:
movl $64, %ecx ; <-- dead
.LBB1_5:
movq $-1, %rax
shrq %cl, %rax
incq %rax
retq
```
bors [Sat, 10 Jun 2017 06:50:12 +0000 (06:50 +0000)]
Auto merge of #42533 - Mark-Simulacrum:macro-parse-speed-small, r=jseyfried
Speed up expansion
This reduces duplication, thereby increasing expansion speed. Based on tests with rust-uinput, this produces a 29x performance win (440 seconds to 15 seconds). I want to land this first, since it's a minimal patch, but with more changes to the macro parsing I can get down to 12 seconds locally.
There is one FIXME added to the code that I'll keep for now since changing it will spread outward and increase the patch size, I think.
fn main() {
let tuple = (1, 2, "Asdfgh");
let zero = Test::Zero;
let one = Test::One(10);
let two = Test::Two(42, "Qwerty".to_owned());
let three = Test::Three(9000,
"Zxcvbn".to_owned(),
vec!["lorem".to_owned(), "ipsum".to_owned(), "dolor".to_owned()]);
println!(""); // breakpoint here
}
```
bors [Fri, 9 Jun 2017 12:49:49 +0000 (12:49 +0000)]
Auto merge of #42507 - ibabushkin:external-span-trans, r=eddyb
Fix translation of external spans
Previously, I noticed that spans from external crates don't generate any output. This limitation is problematic if analysis is performed on one or more external crates, as is the case with [rust-semverver](https://github.com/ibabushkin/rust-semverver). This change should address this behaviour, with the potential drawback that a minor performance hit is to be expected, as spans from potentially large crates have to be translated now.
bors [Fri, 9 Jun 2017 08:03:14 +0000 (08:03 +0000)]
Auto merge of #42504 - michaelwoerister:hash-dep-nodes-prep, r=nikomatsakis
Some preparatory refactorings for hash-based DepNodes
This PR collects some changes that turn out to be necessary for implementing `DepNodes` based on stable hashes (see #42294). The commits are self-contained and mostly straightforward.
The most interesting change here is the introduction of `DefIndices` for things that are not part of the AST: Some pieces of crate metadata now have a `DefIndex` too.
Scott McMurray [Sun, 28 May 2017 03:56:25 +0000 (20:56 -0700)]
Add ctlz_nonzero & cttz_nonzero intrinsics
LLVM currently doesn't remove the "bypass if argument is zero" assembly inside branches where the value is known to be non-zero, pessimizing code that uses uN::leading_zeros
bors [Fri, 9 Jun 2017 04:09:39 +0000 (04:09 +0000)]
Auto merge of #42027 - mjkillough:typedef_assoc_items, r=QuietMisdreavus
Document direct implementations on type aliases.
This improves #32077, but is not a complete fix.
For a type alias `type NewType = AliasedType`, it will include any `impl NewType` and `impl
Trait for NewType` blocks in the documentation for `NewType`.
A complete fix would include the implementations from the aliased type in the type alias' documentation, so that users have a complete picture of methods that are available on the alias. However, to do this properly would require a fix for #14072, as the alias may affect the type parameters of the type alias, making the documentation difficult to understand. (That is, for `type Result = std::result::Result<(), ()>` we would ideally show documentation for `impl Result<(), ()>`, rather than generic documentation for `impl<T, E> Result<T, E>`).
I think this improvement is worthwhile, as it exposes implementations which are not currently documented by rustdoc. The documentation for the implementations on the aliased type are still accessible by clicking through to the docs for that type. (Although perhaps it's now less obvious to the user that they should click-through to get there).
Michael Killough [Tue, 16 May 2017 06:16:44 +0000 (13:16 +0700)]
Document direct implementations on type aliases.
This improves #32077, but is not a complete fix. For a type alias `type
NewType = AliasedType`, it will include any `impl NewType` and `impl
Trait for NewType` blocks in the documentation for `NewType`.
A complete fix would include the implementations from the aliased type
in the type alias' documentation, so that users have a complete
picture of methods that are available on the alias. However, to do this
properly would require a fix for #14072, as the alias may affect the
type parameters of the type alias, making the documentation difficult to
understand. (That is, for `type Result = std::result::Result<(), ()>` we
would ideally show documentation for `impl Result<(), ()>`, rather than
generic documentation for `impl<T, E> Result<T, E>`).
I think this improvement is worthwhile, as it exposes implementations
which are not currently documented by rustdoc. The documentation for the
implementations on the aliased type are still accessible by clicking
through to the docs for that type. (Although perhaps it's now less
obvious to the user that they should click-through to get there).
bors [Thu, 8 Jun 2017 22:21:29 +0000 (22:21 +0000)]
Auto merge of #42491 - RalfJung:bootstrap-help, r=alexcrichton
bootstrap: improve 'build --help' by explaining what exactly the last example does
I recently found myself confused about what exactly gets built how often when I run which command; I think this would have helped me.
One thing I did not touch, but I feel could also be improved, is the wording just above: "For a quick build with a usable compile, you can pass". I am not a native speaker, but this sounds odd to me. Do you mean "For a quick build of a usable compiler" (but then it should say where the usable compiler is produced)? Or do you mean "For a quick build testing if the compiler is usable"? I can reword this, but I'd like to make sure I understand the intent of the message.
What about
```
For a quick build of a usable compiler, you can pass:
./x.py build --stage 1 src/libtest
This will first build everything once (like --stage 0 without further
arguments would), and then use the compiler built in stage 0 to build
src/libtest and its dependencies.
Once this is done, build/$ARCH/stage1 contains a usable compiler.
```
However, I am not sure this is actually true. In particular, why even bother building the libstd in stage 1? AFAIK that ends up in `build/*/stage1-std`, not in `build/*/stage1` (which is filled from `build/*/stage0-*`).
bors [Thu, 8 Jun 2017 19:52:53 +0000 (19:52 +0000)]
Auto merge of #42487 - alexcrichton:smaller-personality, r=vadimcn
std: Avoid panics in rust_eh_personality
This commit removes a few calls to panic and/or assert in `rust_eh_personality`.
This function definitely can't itself panic (that'd probably segfault or do
something else weird) and I was also noticing that a `pub extern fn foo() {}`
cdylib was abnormally large. Turns out all that size was the panicking machinery
brought in by the personality function!
The change here is to return a `Result` internally so we can bubble up the fatal
error, eventually translating to the appropriate error code for the libunwind
ABI.
Alex Crichton [Tue, 6 Jun 2017 18:34:10 +0000 (11:34 -0700)]
std: Avoid panics in rust_eh_personality
This commit removes a few calls to panic and/or assert in `rust_eh_personality`.
This function definitely can't itself panic (that'd probably segfault or do
something else weird) and I was also noticing that a `pub extern fn foo() {}`
cdylib was abnormally large. Turns out all that size was the panicking machinery
brought in by the personality function!
The change here is to return a `Result` internally so we can bubble up the fatal
error, eventually translating to the appropriate error code for the libunwind
ABI.
bors [Thu, 8 Jun 2017 13:52:13 +0000 (13:52 +0000)]
Auto merge of #42500 - hsivonen:neon, r=japaric
Change `llvm.neon.*` to `llvm.arm.neon.*` in the mapping for platform intrinsics
This avoids linker errors when using platform intrinsics on 32-bit ARM with
NEON.
Fixes rust-lang-nursery/simd#10.
I don't have an explanation why the old code might have worked when the `simd` crate was written, since the new LLVM intrinsic naming seems to have existed as early as 2012. Maybe LLVM accepted two naming schemes for a few years and dropped the `llvm.neon.*` version recently? I don't know.
Also, I don't know how to write a unit test for this.
bors [Thu, 8 Jun 2017 08:37:48 +0000 (08:37 +0000)]
Auto merge of #42443 - tommyip:better_closure_msg, r=nikomatsakis
Better closure error message
Use tracked data introduced in #42196 to provide a better closure
error message by showing why a closure implements `FnOnce`.
```
error[E0525]: expected a closure that implements the `Fn` trait, but
this closure only implements `FnOnce`
--> $DIR/issue_26046.rs:4:19
|
4 | let closure = move || {
| ___________________^
5 | | vec
6 | | };
| |_____^
|
note: closure is `FnOnce` because it moves the variable `vec` out of
its environment
--> $DIR/issue_26046.rs:5:9
|
5 | vec
| ^^^
bors [Thu, 8 Jun 2017 06:02:04 +0000 (06:02 +0000)]
Auto merge of #42481 - brson:wingnu, r=alexcrichton
Fix setting PATH during linkage on windows-gnu
This makes the behavior almost exactly the same as before the VS2017 patch, except that on MSVC builds the host bin path is no longer added to PATH. I am not sure that's actually necessary on any platform.
Corey Farwell [Thu, 8 Jun 2017 01:58:44 +0000 (21:58 -0400)]
Rollup merge of #42490 - gaurikholkar:master, r=eddyb
Changing error message from `contains interior mutability` to `may contain interior mutability`
Fixes #40313 . I have changed the message from `contains interior mutability` to `may contain interior mutability` for the following example
```
use std::cell::Cell;
use std::panic::catch_unwind;
fn main() {
let mut x = Cell::new(22);
catch_unwind(|| { x.set(23); });
}
```
which has been added as a ui test.
Also, the message [here](https://github.com/gaurikholkar/rust/blob/master/src/librustc_mir/transform/qualify_consts.rs#L666) and it's respective `compile-fail` test have been modified.
projects / rust.git / log