est31 [Fri, 12 May 2017 06:21:00 +0000 (08:21 +0200)]
Remove some unused macros from the rust codebase
Removes unused macros from:
* libcore
* libcollections
The last use of these two macros was removed in commit b64c9d56700e2c41207166fe8709711ff02488ff
when the char_range_at_reverse function was been removed.
* librustc_errors
Their last use was removed by commits 2f2c3e178325dc1837badcd7573c2c0905fab979
and 11dc974a38fd533aa692cea213305056cd3a6902.
* libsyntax_ext
* librustc_trans
Also, put the otry macro in back/msvc/mod.rs under the
same cfg argument as the places that use it.
bors [Thu, 11 May 2017 22:37:38 +0000 (22:37 +0000)]
Auto merge of #41684 - jethrogb:feature/ntstatus, r=alexcrichton
Windows io::Error: also format NTSTATUS error codes
`NTSTATUS` errors may be encoded as `HRESULT`, see [[MS-ERREF]](https://msdn.microsoft.com/en-us/library/cc231198.aspx). These error codes can still be formatted using `FormatMessageW` but require some different parameters to be passed in.
I wasn't sure if this needed a test and if so, how to test it. Presumably we wouldn't want to make our tests dependent on localization-dependent strings returned from `FormatMessageW`.
Users that get an `err: NTSTATUS` will need to do `io::Error::from_raw_os_error(err|0x1000_0000)` (the equivalent of [`HRESULT_FROM_NT`](https://msdn.microsoft.com/en-us/library/ms693780(VS.85).aspx))
bors [Thu, 11 May 2017 16:56:17 +0000 (16:56 +0000)]
Auto merge of #41913 - nikomatsakis:issue-41849-variance-cycle, r=eddyb
do not fetch variance for items when equating
Fixes #41849. Problem was that evaluating the constant expression
required evaluating a trait, which would equate types, which would
request variance information, which it would then discard. However,
computing the variance information would require determining the type of
a field, which would evaluate the constant expression.
(This problem will potentially arise *later* as we move to more sophisticated
constants, however, where we need to check subtyping. We can tackle that
when we come to it.)
Niko Matsakis [Thu, 11 May 2017 14:54:19 +0000 (10:54 -0400)]
do not fetch variance for items when equating
Fixes #41849. Problem was that evaluating the constant expression
required evaluating a trait, which would equate types, which would
request variance information, which it would then discard. However,
computing the variance information would require determining the type of
a field, which would evaluate the constant expression.
(This problem will potentially arise *later* as we move to more sophisticated
constants, however, where we need to check subtyping. We can tackle that
when we come to it.)
bors [Thu, 11 May 2017 14:05:37 +0000 (14:05 +0000)]
Auto merge of #41864 - malbarbo:android-docker, r=alexcrichton
Add disabled android host builders
Introduce the concept of disabled builder. A disabled builder is one that is not run by travis. It is intended to be run by the user who wants a rustc for a tier 2 or 3 platform. Off corse, there is no guarantee that it will work.
bors [Thu, 11 May 2017 11:27:43 +0000 (11:27 +0000)]
Auto merge of #41863 - malbarbo:update-android-builder, r=alexcrichton
ci: Update android ndk and sdk
Make install-sdk.sh and install-ndk.sh more generic so future updates can be made directly on Dockerfile. Update ndk to r13b, which will be necessary to make host builds for android (in the future). Update sdk to r25.2.5 (maybe some emulator performance improvement).
Corey Farwell [Thu, 11 May 2017 04:21:27 +0000 (00:21 -0400)]
Rollup merge of #41877 - eddyb:gdb-force-rust, r=michaelwoerister
compiletest: force GDB to print values in the Rust format.
Based on @nodakai's https://github.com/rust-lang/rust/issues/40557#issuecomment-294368330 and @infinity0's https://github.com/rust-lang/rust/issues/40557#issuecomment-300133591.
Fixes #40557.
Corey Farwell [Thu, 11 May 2017 04:21:26 +0000 (00:21 -0400)]
Rollup merge of #41873 - michaelwoerister:fix-filemap-hash-lookup, r=nikomatsakis
ICH: Handle case of removed FileMaps.
This PR fixes a bug introduced in #41709 where removing a source file between compilation sessions would cause an ICE:
https://travis-ci.org/rust-icci/crossbeam/jobs/230582234#L633
Corey Farwell [Thu, 11 May 2017 04:21:24 +0000 (00:21 -0400)]
Rollup merge of #41192 - zackw:eprintln, r=alexcrichton
Add `eprint!` and `eprintln!` macros to the prelude.
These are exactly the same as `print!` and `println!` except that they write to stderr instead of stdout. Issues #39228 and #40528; previous PR #39229; accepted RFC rust-lang/rfcs#1869; proposed revision to The Book rust-lang/book#615.
I have _not_ revised this any since the original submission; I will do that later this week. I wanted to get this PR in place since it's been quite a while since the RFC was merged.
Known outstanding review comments:
* [x] @steveklabnik requested a new chapter for the unstable version of The Book -- please see if the proposed revisions to the second edition cover it.
* [x] @nodakai asked if it were possible to merge the internal methods `_print` and `_eprint` - not completely, since they both refer to different internal globals which we don't want to expose, but I will see if some duplication can be factored out.
Steve Klabnik [Wed, 10 May 2017 15:18:33 +0000 (17:18 +0200)]
Rollup merge of #41854 - gamazeps:thread-spawn-doc, r=steveklabnik
[Doc] Improve `thread::spawn` documentation
Part of #29378
- Add two examples to `thread::spawn` doumentation that show common uses of threads.
- Add a link to `thread::Builder` in the `thread::spawn` documentation for configuring threads.
- Add a link to `thread::spawn` in `thread::Builder` in order to avoid documentation duplication.
* Factor out the nigh-identical bodies of `_print` and `_eprint` to a helper
function `print_to` (I was sorely tempted to call it `_doprnt`).
* Update the issue number for the unstable `eprint` feature.
* Add entries to the "unstable book" for `eprint` and `eprint_internal`.
* Style corrections to the documentation.
bors [Wed, 10 May 2017 11:37:22 +0000 (11:37 +0000)]
Auto merge of #41815 - Yamakaky:improve-backtrace-bottom, r=alexcrichton
Improve cleaning of the bottom of the backtrace
Following https://github.com/rust-lang/rust/pull/40264. It only cleans the bottom of the trace (after the main). It handles correctly the normal main, tests, benchmarks and threads.
I kept `skipped_before` since it will be used later for the cleaning of the top.
bors [Wed, 10 May 2017 08:54:50 +0000 (08:54 +0000)]
Auto merge of #41764 - scottmcm:faster-reverse, r=brson
Make [u8]::reverse() 5x faster
Since LLVM doesn't vectorize the loop for us, do unaligned reads of a larger type and use LLVM's bswap intrinsic to do the reversing of the actual bytes. cfg!-restricted to x86 and x86_64, as I assume it wouldn't help on things like ARMv5.
Also makes [u16]::reverse() a more modest 1.5x faster by loading/storing u32 and swapping the u16s with ROT16.
Thank you ptr::*_unaligned for making this easy :)
Benchmark results (from my i5-2500K):
```text
# Before
test slice::reverse_u8 ... bench: 273,836 ns/iter (+/- 15,592) = 3829 MB/s
test slice::reverse_u16 ... bench: 139,793 ns/iter (+/- 17,748) = 7500 MB/s
test slice::reverse_u32 ... bench: 74,997 ns/iter (+/- 5,130) = 13981 MB/s
test slice::reverse_u64 ... bench: 47,452 ns/iter (+/- 2,213) = 22097 MB/s
# After
test slice::reverse_u8 ... bench: 52,170 ns/iter (+/- 3,962) = 20099 MB/s
test slice::reverse_u16 ... bench: 93,330 ns/iter (+/- 4,412) = 11235 MB/s
test slice::reverse_u32 ... bench: 74,731 ns/iter (+/- 1,425) = 14031 MB/s
test slice::reverse_u64 ... bench: 47,556 ns/iter (+/- 3,025) = 22049 MB/s
```
If you're curious about the assembly, instead of doing this
```
movzx eax, byte ptr [rdi]
movzx ecx, byte ptr [rsi]
mov byte ptr [rdi], cl
mov byte ptr [rsi], al
```
it does this
```
mov rax, qword ptr [rdx]
mov rbx, qword ptr [r11 + rcx - 8]
bswap rbx
mov qword ptr [rdx], rbx
bswap rax
mov qword ptr [r11 + rcx - 8], rax
```
bors [Wed, 10 May 2017 03:27:36 +0000 (03:27 +0000)]
Auto merge of #41659 - bluss:clone-split-whitespace, r=aturon
impl Clone for .split_whitespace()
Use custom closure structs for the predicates so that the iterator's
clone can simply be derived. This should also reduce virtual call
overhead by not using function pointers.
bors [Tue, 9 May 2017 19:31:35 +0000 (19:31 +0000)]
Auto merge of #41830 - jonhoo:update-cargo, r=alexcrichton
Bump cargo for rust-lang/cargo#4000
rust-lang/cargo#4000 recently landed, which fixes warnings about using `-Z` when `CARGO_INCREMENTAL` is set while running stable/beta builds. As #41751 has now landed, these warnings will turn to errors in the next release, so getting the cargo fix in place is necessary unless we want people confused about why they can no longer compile anything on stable/beta.
Yamakaky [Sat, 4 Mar 2017 15:27:52 +0000 (10:27 -0500)]
Don't show the std frames before user code on unwinding.
When `RUST_BACKTRACE=1`, remove all frames after
`__rust_maybe_catch_panic`. Tested on `main`, threads, tests and
benches. Cleaning of the top of the stacktrace is let to a future PR.
bors [Tue, 9 May 2017 16:31:07 +0000 (16:31 +0000)]
Auto merge of #41814 - gamazeps:thread-struct-doc, r=steveklabnik
[Doc] improve `thread::Thread` and `thread::Builder` documentations
Part of #29378
- Adds information about the stack_size when using `Builder`. This might be considered too low level, but I assume that if someone wants to create their own builder instead of using `thread::spawn` they may be interested in that info.
- Updates the `thread::Thread` structure doc, mostly by explaining how to get one, the previous example was removed because it was not related to `thread::Thread`, but rather to `thread::Builder::name`.
Not much is present there, mostly because this API is not often used (the only method that seems useful is `unpark`, which is documented in #41809).
bors [Tue, 9 May 2017 11:55:37 +0000 (11:55 +0000)]
Auto merge of #41709 - michaelwoerister:close-metadata-ich-holes, r=nikomatsakis
incr.comp.: Hash more pieces of crate metadata to detect changes there.
This PR adds incr. comp. hashes for non-`Entry` pieces of data in crate metadata.
The first part of it I like: `EntryBuilder` is refactored into the more generally applicable `IsolatedEncoder` which provides means of encoding something into metadata while also feeding the encoded data into an incr. comp. hash. We already did this for `Entry`, now we are doing it for various other pieces of data too, like the set of exported symbols and so on. The hashes generated there are persisted together with the per-`Entry` hashes and are also used for dep-graph dirtying the same way.
The second part of the PR I'm not entirely happy with: In order to make sure that we don't forget registering a read to the new `DepNodes` introduced here, I added the `Tracked<T>` struct. This struct wraps a value and requires a `DepNode` when accessing the wrapped value. This makes it harder to overlook adding read edges in the right places and works just fine.
However, crate metadata is already used in places where there is no `tcx` yet or even in places where no `cnum` has been assigned -- this makes it harder to apply this feature consistently or implement it ergonomically. The result is not too bad but there's a bit more code churn and a bit more opportunity to get something wrong than I would have liked. On the other hand, wrapping things in `Tracked<T>` already has revealed some bugs, so there's definitely some value in it.
This is still a work in progress:
- [x] I need to write some test cases.
- [x] Accessing the CodeMap should really be dependency tracked too, especially with the new path-remapping feature.
Corey Farwell [Tue, 9 May 2017 02:34:52 +0000 (22:34 -0400)]
Rollup merge of #41838 - z1mvader:fix_fn_args_coerce_closure, r=nikomatsakis
Fixed argument inference for closures when coercing into 'fn'
This fixes https://github.com/rust-lang/rust/issues/41755. The tests `compile-fail/closure-no-fn.rs` and `compile-fail/issue-40000.rs` were modified. A new test `run-pass/closure_to_fn_coercion-expected-types.rs` was added
1) changed "long way into" to "long way toward"
2) changed "developer lives" to "developers' lives"
3) removed the "either... or..." format from second paragraph because there are more than 2 options
4) Minor revisions to paragraphs 3-6 to make them more consistent in format and to fix minor grammar issues.
Jing Zhao [Mon, 8 May 2017 20:33:54 +0000 (13:33 -0700)]
Grammar fixes to rustc-ux-guidelines.md
1) changed "long way into" to "long way toward"
2) changed "developer lives" to "developers' lives"
3) removed the "either... or..." format from second paragraph because there are more than 2 options
4) Minor revisions to paragraphs 3-6 to make them more consistent in format and to fix minor grammar issues.
bors [Mon, 8 May 2017 12:00:22 +0000 (12:00 +0000)]
Auto merge of #41745 - oli-obk:diagnostics, r=jonathandturner
Remove need for &format!(...) or &&"" dances in `span_label` calls
These were always a thorn in my eye. Note that this will monomorphize to two impls, one for `String` and one for `&str`. But I think that cost is worth the ergonomics at the call sites that can be seen throughout this PR.
bors [Mon, 8 May 2017 05:29:24 +0000 (05:29 +0000)]
Auto merge of #41818 - michaelwu:hvx-v60, r=nagisa
Add support for Hexagon v60 HVX intrinsics
HVX is a SIMD coprocessor available on newer hexagon cores. It can be configured for 512 or 1024 bit registers, and some instructions use pairs of registers. It only does integer operations, but it probably has every integer operation you'd want for 8/16/32 bit elements.
There are a lot of intrinsics. The generator outputs 582 of them. I probably got some wrong. I did some scripting to make sure that every llvm intrinsic name exists, but intrinsic names provided for programs have only been compared by eye to Qualcomm's own names. 64/128 is also appended to the names to select between 512/1024 bit. The C intrinsics don't do this, but they only expose one set, selected at compile time.
The json specifying the intrinsics required a bit of duplication since I didn't see an easy way to specify combinations of signed/unsigned types (eg. u(8-16) and s(16-32)). I also didn't see an easy way to specify variants of instructions like saturating or rounding.
Basic multiplication and load/store tested on the hexagon simulator.
bors [Sun, 7 May 2017 16:20:15 +0000 (16:20 +0000)]
Auto merge of #41791 - Mark-Simulacrum:doc-guidelines, r=frewsxcv
Minor cleanup of UX guidelines.
I think this fixes https://github.com/rust-lang/rust/issues/34808. It covers the [long error code explanations normalization] by linking to the RFC, and cleaning up the list where long diagnostics are defined. While the [error message overhaul] isn't covered directly, I'm not really sure that more than the [existing section] on the error/warning/help messages is warranted; the overhaul linked didn't really specify any new guidelines, primarily just changing the output format.
bors [Sun, 7 May 2017 13:57:36 +0000 (13:57 +0000)]
Auto merge of #40857 - estebank:recursive, r=arielb1
Point at fields that make the type recursive
On recursive types of infinite size, point at all the fields that make
the type recursive.
```rust
struct Foo {
bar: Bar,
}
struct Bar {
foo: Foo,
}
```
outputs
```
error[E0072]: recursive type `Foo` has infinite size
--> file.rs:1:1
1 | struct Foo {
| ^^^^^^^^^^ recursive type has infinite size
2 | bar: Bar,
| -------- recursive here
|
= help: insert indirection (e.g., a `Box`, `Rc`, or `&`) at some point to make `Foo` representable
error[E0072]: recursive type `Bar` has infinite size
--> file.rs:5:1
|
5 | struct Bar {
| ^^^^^^^^^^ recursive type has infinite size
6 | foo: Foo,
| -------- recursive here
|
= help: insert indirection (e.g., a `Box`, `Rc`, or `&`) at some point to make `Bar` representable
```
bors [Sun, 7 May 2017 10:52:26 +0000 (10:52 +0000)]
Auto merge of #41785 - Mark-Simulacrum:issue-41783, r=GuillaumeGomez
Allow # to appear in rustdoc code output.
"##" at the start of a trimmed rustdoc line is now cut to "#" and then
shown. If the user wanted to show "##", they can type "###".
I'm somewhat concerned about the potential implications for users, since this does make a potentially backwards-incompatible change. Previously, `##` had no special handling, and now we do change it. However, I'm not really sure what we can do here to improve this, and I can't think of any cases where `##` would likely be correct in a code block, though of course I could be wrong.