bors [Wed, 11 Oct 2017 05:18:13 +0000 (05:18 +0000)]
Auto merge of #45193 - alexcrichton:fix-travis, r=alexcrichton
ci: Fix installing the Android SDK
Apparently the https urls are broken due to some certificate validation
whatnots, and so far the least intrusive solution I've found is to just disable
that.
Alex Crichton [Wed, 11 Oct 2017 01:59:40 +0000 (18:59 -0700)]
ci: Fix installing the Android SDK
Apparently the https urls are broken due to some certificate validation
whatnots, and so far the least intrusive solution I've found is to just disable
that.
Steve Klabnik [Wed, 11 Oct 2017 00:22:27 +0000 (20:22 -0400)]
Rollup merge of #45148 - gaurikholkar:master, r=nikomatsakis
Update let-expressions.rs with DepNode labels
As a part of #44924, the PR has tests verified for the following dependency nodes for **let-expressions**
```
- MirValidated
- MirOptimized
- TypeCheckTables
- TypeOfItem
- GenericsOfItem
- PredicatesOfItem
- FnSignature
```
As we are more concerned with the function body, the following fingerprints do not change over compilation sessions.
```- TypeOfItem
- GenericsOfItem
- PredicatesOfItem
- FnSignature
```
Steve Klabnik [Wed, 11 Oct 2017 00:22:24 +0000 (20:22 -0400)]
Rollup merge of #45071 - tromey:use-gdb-lazy-string, r=michaelwoerister
Implement display_hint in gdb pretty printers
A few pretty-printers were returning a quoted string from their
to_string method. It's preferable in gdb to return a lazy string and to
let gdb handle the display by having a "display_hint" method that
returns "string" -- it lets gdb settings (like "set print ...") work, it
handles corrupted strings a bit better, and it passes the information
along to IDEs.
kennytm [Tue, 10 Oct 2017 12:08:28 +0000 (20:08 +0800)]
Rollup merge of #45135 - michaelwoerister:move-incr-comp-with-macro-export, r=alexcrichton
incr.comp.: Move macro-export test case to src/test/incremental.
`compile-fail/incr_comp_with_macro_export.rs` was trying to role its own incremental compilation setup. This started to cause problems. There's no reason to not just make this a regular `src/test/incremental` test.
kennytm [Tue, 10 Oct 2017 12:08:26 +0000 (20:08 +0800)]
Rollup merge of #45108 - phil-opp:patch-2, r=japaric
Fix data-layout field in x86_64-unknown-linux-gnu.json test file
The current data-layout causes the following error:
> rustc: /checkout/src/llvm/lib/CodeGen/MachineFunction.cpp:151: void llvm::MachineFunction::init(): Assertion `Target.isCompatibleDataLayout(getDataLayout()) && "Can't create a MachineFunction using a Module with a " "Target-incompatible DataLayout attached\n"' failed.
The new value was generated according to [this comment by @japaric](https://github.com/rust-lang/rust/issues/31367#issuecomment-213595571).
kennytm [Tue, 10 Oct 2017 12:08:24 +0000 (20:08 +0800)]
Rollup merge of #45099 - mikeyhew:fix-astconv-self-type-comments, r=nikomatsakis
Update comments referring to old check_method_self_type
I was browsing the code base, trying to figure out how #44874 could be implemented, and noticed some comments that were out of date and a bit misleading (`check_method_self_type` has since been renamed to `check_method_receiver`). Thought it would be an easy first contribution to Rust!
bors [Tue, 10 Oct 2017 14:26:13 +0000 (14:26 +0000)]
Auto merge of #45170 - rust-lang:aphs-no-unsynchronised-llvm-err-global, r=alexcrichton
Band-aid fix to stop race conditions in llvm errors
This is a big hammer, but should be effective at completely removing a
few issues, including inconsistent error messages and segfaults when
LLVM workers race to report results
`LLVM_THREAD_LOCAL` has been present in LLVM since 8 months before 3.7
(the earliest supported LLVM version that Rust can use)
Maybe fixes #43402 (third time lucky?)
r? @alexcrichton
------
You can see that in https://github.com/rust-lang/rust/blob/5f578dfad0dd5d43b28eff71a7e857d10c3f55fe/src/librustc_trans/back/write.rs#L75-L100 there's a small window where the static global error message (made thread local in this PR) could be altered by another thread.
Note that we can't use `thread_local` because gcc 4.7 (permitted according to the readme) does not support it.
Maybe ideally all the functions should be modified to not use a global, but this PR makes things deterministic at least. My only hesitation is whether errors are checked in different threads to where they occur, but I figure that's probably unlikely (and is less bad than racing code).
As an aside, segfault evidence before this patch when I was doing some debugging:
```
$ while grep 'No such file or directory' log2; do RUST_LOG=debug ./build/x86_64-unknown-linux-gnu/stage1/bin/rustc -o "" y.rs >log2 2>&1; done
error: could not write output to : No such file or directory
error: could not write output to : No such file or directory
error: could not write output to : No such file or directory
error: could not write output to : No such file or directory
error: could not write output to : No such file or directory
error: could not write output to : No such file or directory
error: could not write output to : No such file or directory
Segmentation fault (core dumped)
error: could not write output to : No such file or directory
error: could not write output to : No such file or directory
```
Band-aid fix to stop race conditions in llvm errors
This is a big hammer, but should be effective at completely removing a
few issues, including inconsistent error messages and segfaults when
LLVM workers race to report results
LLVM_THREAD_LOCAL has been present in LLVM since 8 months before 3.7
(the earliest supported LLVM version that Rust can use)
bors [Tue, 10 Oct 2017 11:07:25 +0000 (11:07 +0000)]
Auto merge of #44877 - nvzqz:box-conversions, r=alexcrichton
Improve raw Box conversions
This PR has two goals:
- Reduce use of `mem::transmute` in `Box` conversions
I understand that `mem::transmute`-ing non `#[repr(C)]` types is implementation-defined behavior. This may not matter within the reference implementation of Rust, but I believe it's important to remain consistent. For example, I noticed that `str::from_utf8_unchecked` went from using `mem::transmute` to using pointer casts.
- Make `Box` pointer conversions more straightforward regarding `Unique`
Rename test Linux target to avoid conflict with built-in target
It seems like the file wasn't actually used, since there is a built-in target with the same name. See https://github.com/rust-lang/rust/pull/45108#issuecomment-335173165 for more details.
bors [Mon, 9 Oct 2017 16:31:15 +0000 (16:31 +0000)]
Auto merge of #45111 - aidanhs:aphs-bubble-worker-failures, r=alexcrichton
Don't panic in the coordinator thread, bubble up the failure
Fixes #43402 (take 2)
Followup to #45019, this makes the coordinator thread not panic on worker failures since they can be reported reasonably back in the main thread.
The output also now has no evidence of backtraces at all, unlike the previous PR:
```
$ ./build/x86_64-unknown-linux-gnu/stage1/bin/rustc -o "" x.rs
error: could not write output to : No such file or directory
kennytm [Mon, 9 Oct 2017 16:16:27 +0000 (00:16 +0800)]
Rollup merge of #45125 - bleibig:grammar-update, r=alexcrichton
Update grammar to parse current rust syntax
Mainly addressing #32723. This PR updates the bison grammar so that it can parse the current rust syntax, except for feature-gated syntax additions. It has been tested with all the tests in run-pass.
The grammar in this repo doesn't have build logic anymore, but you can test it out in https://github.com/bleibig/rust-grammar, which has all of what's in this PR. If you are interested in having build logic and grammar tests again, I can look into implementing that as well.
I'm aware that things are somewhat undecided as to what an official rust grammar should be from the discussion in #30942. With this PR we can go back to having an up-to-date flex/bison based grammar, but the rustypop grammar looks interesting as well.
kennytm [Mon, 9 Oct 2017 16:16:26 +0000 (00:16 +0800)]
Rollup merge of #45120 - johnthagen:none-identity-test, r=sfackler
Use identity operator `is` when comparing to None
This is very minor, but idiomatic Python code uses `is` for comparisons to `None`. This is because semantically we want to compare to the "identity" of `None`, not its value.
See [PEP8 for details](https://www.python.org/dev/peps/pep-0008/#programming-recommendations).
bors [Mon, 9 Oct 2017 14:00:12 +0000 (14:00 +0000)]
Auto merge of #45075 - alexcrichton:inline-less, r=michaelwoerister
rustc: Don't inline in CGUs at -O0
This commit tweaks the behavior of inlining functions into multiple codegen
units when rustc is compiling in debug mode. Today rustc will unconditionally
treat `#[inline]` functions by translating them into all codegen units that
they're needed within, marking the linkage as `internal`. This commit changes
the behavior so that in debug mode (compiling at `-O0`) rustc will instead only
translate `#[inline]` functions into *one* codegen unit, forcing all other
codegen units to reference this one copy.
The goal here is to improve debug compile times by reducing the amount of
translation that happens on behalf of multiple codegen units. It was discovered
in #44941 that increasing the number of codegen units had the adverse side
effect of increasing the overal work done by the compiler, and the suspicion
here was that the compiler was inlining, translating, and codegen'ing more
functions with more codegen units (for example `String` would be basically
inlined into all codegen units if used). The strategy in this commit should
reduce the cost of `#[inline]` functions to being equivalent to one codegen
unit, which is only translating and codegen'ing inline functions once.
Collected [data] shows that this does indeed improve the situation from [before]
as the overall cpu-clock time increases at a much slower rate and when pinned to
one core rustc does not consume significantly more wall clock time than with one
codegen unit.
One caveat of this commit is that the symbol names for inlined functions that
are only translated once needed some slight tweaking. These inline functions
could be translated into multiple crates and we need to make sure the symbols
don't collideA so the crate name/disambiguator is mixed in to the symbol name
hash in these situations.
bors [Mon, 9 Oct 2017 04:59:02 +0000 (04:59 +0000)]
Auto merge of #45041 - est31:master, r=alexcrichton
Remove support for the PNaCl target (le32-unknown-nacl)
This removes support for the `le32-unknown-nacl` target which is currently supported by rustc on tier 3. Despite the "nacl" in the name, the target doesn't output native code (x86, ARM, MIPS), instead it outputs binaries in the PNaCl format.
There are two reasons for the removal:
* Google [has announced](https://blog.chromium.org/2017/05/goodbye-pnacl-hello-webassembly.html) deprecation of the PNaCl format. The suggestion is to migrate to wasm. Happens we already have a wasm backend!
* Our PNaCl LLVM backend is provided by the fastcomp patch set that the LLVM fork used by rustc contains in addition to vanilla LLVM (`src/llvm/lib/Target/JSBackend/NaCl`). Upstream LLVM doesn't have PNaCl support. Removing PNaCl support will enable us to move away from fastcomp (#44006) and have a lighter set of patches on top of upstream LLVM inside our LLVM fork. This will help distribution packagers of Rust.
bors [Sun, 8 Oct 2017 18:12:26 +0000 (18:12 +0000)]
Auto merge of #45016 - pnkfelix:mir-borrowck-gather-and-signal-move-errors, r=nikomatsakis
MIR-borrowck: gather and signal any move errors
When building up the `MoveData` structure for a given MIR, also accumulate any erroneous actions, and then report all of those errors when the construction is complete.
This PR adds a host of move-related error constructor methods to `trait BorrowckErrors`. I think I got the notes right; but we should plan to audit all of the notes before turning MIR-borrowck on by default.
bors [Sun, 8 Oct 2017 10:43:45 +0000 (10:43 +0000)]
Auto merge of #45012 - Gankro:noalias, r=arielb1
Add -Zmutable-noalias flag
We disabled noalias on mutable references a long time ago when it was clear that llvm was incorrectly handling this in relation to unwinding edges.
Since then, a few things have happened:
* llvm has cleaned up a bunch of the issues (I'm told)
* we've added a nounwind codegen option
As such, I would like to add this -Z flag so that we can evaluate if the codegen bugs still exist, and if this significantly affects the codegen of different projects, with an eye towards permanently re-enabling it (or at least making it a stable option).
bors [Sun, 8 Oct 2017 08:21:24 +0000 (08:21 +0000)]
Auto merge of #45001 - bgermann:master, r=alexcrichton
Add builder for Solaris and merge it with Fuchsia's builder
The new Solaris builder can be used to build rust-std.
The dilos illumos distribution was chosen, because illumos is free software
as opposed to Oracle Solaris and dilos is the only illumos distribution that
supports x86_64 and sparcv9 at the same level.
kennytm [Sun, 8 Oct 2017 05:39:06 +0000 (13:39 +0800)]
Rollup merge of #45094 - japaric:strict-align, r=alexcrichton
enable strict alignment (+strict-align) on ARMv6
As discovered in #44538 ARMv6 devices may or may not support unaligned memory accesses. ARMv6
Linux *seems* to have no problem with unaligned accesses but this is because the kernel is stepping
in to fix each unaligned memory access -- this incurs in a performance penalty.
This commit enforces aligned memory accesses on all our in-tree ARM targets that may be used with
ARMv6 devices. This should improve performance of Rust programs on ARMv6 devices. For the record,
clang also applies this attribute when targeting ARMv6 devices that are not running Darwin or
NetBSD.
kennytm [Sun, 8 Oct 2017 05:39:05 +0000 (13:39 +0800)]
Rollup merge of #45090 - rust-lang:petrochenkov-patch-1, r=alexcrichton
Document that `-C ar=PATH` doesn't do anything
Are there any plans to use an external archiver in the future?
IIRC, it was used before, but its use was replaced with LLVM's built-in archive management machinery. I can't found a relevant PR though. EDIT: Found it - https://github.com/rust-lang/rust/pull/26926!
The `-C` option is stable so it still can't be removed right away even if there are no plans to use it (but maybe it can be deprecated?).
Target specifications have a field for archiver as well, which is unused too (these ones are unstable, so I guess it can be removed).
kennytm [Sun, 8 Oct 2017 05:39:04 +0000 (13:39 +0800)]
Rollup merge of #45083 - fhartwig:slice-read-to-end, r=bluss
Add read_to_end implementation to &[u8]'s Read impl
The default impl for read_to_end does a bunch of bookkeeping
that isn't necessary for slices and is about 4 times slower
on my machine.
The following benchmark takes about 30 ns before this change and about 7 ns after:
```
#[bench]
fn bench_read_std(b: &mut Bencher) {
let data = vec![0u8; 100];
let mut v = Vec::with_capacity(200);
b.iter(|| {
let mut s = data.as_slice();
v.clear();
s.read_to_end(&mut v).unwrap();
});
}
```
This solves the easy part of https://github.com/rust-lang/rust/issues/44819 (I think extending this to `Take<&[u8]> `would require specialization)
kennytm [Sun, 8 Oct 2017 05:39:01 +0000 (13:39 +0800)]
Rollup merge of #45058 - hunteke:fix_rustc_private_typo_2017Oct, r=shepmaster
Fix typo, per #45057.
This looks like a simple string -- one character -- fix. Given that I'm currently running low on battery, I have not actually compiled and tested this. But I am fully confident this passes muster. If not, I'll be maintainer-educated, yes? ;-)
kennytm [Sun, 8 Oct 2017 05:38:59 +0000 (13:38 +0800)]
Rollup merge of #45052 - steveklabnik:gh44105, r=dtolnay
Modify Rc/Arc language around mutability
There are a few exceptions to the rule that Arc/Rc are immutable. Rather
than dig into the details, add "generally" to hint at this difference,
as it's kind of a distraction at this point in the docs.
Additionally, Arc's docs were slightly different here generally, so add
in both the existing language and the exception.
bors [Sun, 8 Oct 2017 03:02:35 +0000 (03:02 +0000)]
Auto merge of #44983 - vitiral:dirty_clean_groups, r=michaelwoerister
groundwork for rustc_clean/dirty improvements
This is a WIP PR that needs mentoring from @michaelwoerister.
There are several TODOs but no outstanding questions (except for the main one -- **is this the right approach?**)
This is the plumbing for supporing groups in `rustc_clean(labels="...")`, as well as supporting an `except="..."` which will remove the excepted labels in the "clean" check and then assert that they are dirty (this is still TODO).
See the code TODO's and example comments for a rough design.
I'd like to know if this is the design you would like to do, and then I can go about actually filling out the groups and implementing the remaining logic.
Alex Crichton [Fri, 6 Oct 2017 21:59:33 +0000 (14:59 -0700)]
rustc: Don't inline in CGUs at -O0
This commit tweaks the behavior of inlining functions into multiple codegen
units when rustc is compiling in debug mode. Today rustc will unconditionally
treat `#[inline]` functions by translating them into all codegen units that
they're needed within, marking the linkage as `internal`. This commit changes
the behavior so that in debug mode (compiling at `-O0`) rustc will instead only
translate `#[inline]` functions into *one* codegen unit, forcing all other
codegen units to reference this one copy.
The goal here is to improve debug compile times by reducing the amount of
translation that happens on behalf of multiple codegen units. It was discovered
in #44941 that increasing the number of codegen units had the adverse side
effect of increasing the overal work done by the compiler, and the suspicion
here was that the compiler was inlining, translating, and codegen'ing more
functions with more codegen units (for example `String` would be basically
inlined into all codegen units if used). The strategy in this commit should
reduce the cost of `#[inline]` functions to being equivalent to one codegen
unit, which is only translating and codegen'ing inline functions once.
Collected [data] shows that this does indeed improve the situation from [before]
as the overall cpu-clock time increases at a much slower rate and when pinned to
one core rustc does not consume significantly more wall clock time than with one
codegen unit.
One caveat of this commit is that the symbol names for inlined functions that
are only translated once needed some slight tweaking. These inline functions
could be translated into multiple crates and we need to make sure the symbols
don't collideA so the crate name/disambiguator is mixed in to the symbol name
hash in these situations.
bors [Sun, 8 Oct 2017 00:40:58 +0000 (00:40 +0000)]
Auto merge of #44978 - jamesmunns:armv5te-os-atomics, r=alexcrichton
Allow atomic operations up to 32 bits
The ARMv5te platform does not have instruction-level support for atomics, however the kernel provides [user space helpers] which can be used to perform atomic operations. When linked with `libgcc`, the atomic symbols needed by Rust will be provided, rather than CPU level intrinsics.
[user space helpers]: https://www.kernel.org/doc/Documentation/arm/kernel_user_helpers.txt
32-bit versions of these kernel level helpers were introduced in Linux Kernel 2.6.12, and 64-bit version of these kernel level helpers were introduced in Linux Kernel 3.1. I have selected 32 bit versions as std currently only requires Linux version 2.6.18 and above as far as I am aware.
As this target is specifically linux and gnueabi, it is reasonable to assume the Linux Kernel and libc will be available for the target. There is a large performance penalty, as we are not using CPU level intrinsics, however this penalty is likely preferable to not having the target at all.
I have used this change in a custom target (along with xargo) to build std, as well as a number of higher level crates.
## Additional information
For reference, here is what a a code snippet decompiles to:
```rust
use std::sync::atomic::{AtomicIsize, Ordering};
bors [Sat, 7 Oct 2017 22:18:20 +0000 (22:18 +0000)]
Auto merge of #44841 - alexcrichton:thinlto, r=michaelwoerister
rustc: Implement ThinLTO
This commit is an implementation of LLVM's ThinLTO for consumption in rustc
itself. Currently today LTO works by merging all relevant LLVM modules into one
and then running optimization passes. "Thin" LTO operates differently by having
more sharded work and allowing parallelism opportunities between optimizing
codegen units. Further down the road Thin LTO also allows *incremental* LTO
which should enable even faster release builds without compromising on the
performance we have today.
This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then
also implements two forms of ThinLTO:
* In one mode we'll *only* perform ThinLTO over the codegen units produced in a
single compilation. That is, we won't load upstream rlibs, but we'll instead
just perform ThinLTO amongst all codegen units produced by the compiler for
the local crate. This is intended to emulate a desired end point where we have
codegen units turned on by default for all crates and ThinLTO allows us to do
this without performance loss.
* In anther mode, like full LTO today, we'll optimize all upstream dependencies
in "thin" mode. Unlike today, however, this LTO step is fully parallelized so
should finish much more quickly.
There's a good bit of comments about what the implementation is doing and where
it came from, but the tl;dr; is that currently most of the support here is
copied from upstream LLVM. This code duplication is done for a number of
reasons:
* Controlling parallelism means we can use the existing jobserver support to
avoid overloading machines.
* We will likely want a slightly different form of incremental caching which
integrates with our own incremental strategy, but this is yet to be
determined.
* This buys us some flexibility about when/where we run ThinLTO, as well as
having it tailored to fit our needs for the time being.
* Finally this allows us to reuse some artifacts such as our `TargetMachine`
creation, where all our options we used today aren't necessarily supported by
upstream LLVM yet.
My hope is that we can get some experience with this copy/paste in tree and then
eventually upstream some work to LLVM itself to avoid the duplication while
still ensuring our needs are met. Otherwise I fear that maintaining these
bindings may be quite costly over the years with LLVM updates!
Jorge Aparicio [Sat, 7 Oct 2017 18:48:25 +0000 (20:48 +0200)]
enable strict alignment (+strict-align) on ARMv6
As discovered in #44538 ARMv6 devices may or may not support unaligned memory accesses. ARMv6
Linux *seems* to have no problem with unaligned accesses but this is because the kernel is stepping
in to fix each unaligned memory access -- this incurs in a performance penalty.
This commit enforces aligned memory accesses on all our in-tree ARM targets that may be used with
ARMv6 devices. This should improve performance of Rust programs on ARMv6 devices. For the record,
clang also applies this attribute when targeting ARMv6 devices that are not running Darwin or
NetBSD.
kennytm [Sat, 7 Oct 2017 17:39:27 +0000 (01:39 +0800)]
debuginfo-test: Fix #45086.
LLDB's output may be None instead of '', and that will cause type
mismatch when normalize_whitespace() expects a string instead of
None. This commit simply ensures we do pass '' even if the output
is None.
Alex Crichton [Sun, 23 Jul 2017 15:14:38 +0000 (08:14 -0700)]
rustc: Implement ThinLTO
This commit is an implementation of LLVM's ThinLTO for consumption in rustc
itself. Currently today LTO works by merging all relevant LLVM modules into one
and then running optimization passes. "Thin" LTO operates differently by having
more sharded work and allowing parallelism opportunities between optimizing
codegen units. Further down the road Thin LTO also allows *incremental* LTO
which should enable even faster release builds without compromising on the
performance we have today.
This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then
also implements two forms of ThinLTO:
* In one mode we'll *only* perform ThinLTO over the codegen units produced in a
single compilation. That is, we won't load upstream rlibs, but we'll instead
just perform ThinLTO amongst all codegen units produced by the compiler for
the local crate. This is intended to emulate a desired end point where we have
codegen units turned on by default for all crates and ThinLTO allows us to do
this without performance loss.
* In anther mode, like full LTO today, we'll optimize all upstream dependencies
in "thin" mode. Unlike today, however, this LTO step is fully parallelized so
should finish much more quickly.
There's a good bit of comments about what the implementation is doing and where
it came from, but the tl;dr; is that currently most of the support here is
copied from upstream LLVM. This code duplication is done for a number of
reasons:
* Controlling parallelism means we can use the existing jobserver support to
avoid overloading machines.
* We will likely want a slightly different form of incremental caching which
integrates with our own incremental strategy, but this is yet to be
determined.
* This buys us some flexibility about when/where we run ThinLTO, as well as
having it tailored to fit our needs for the time being.
* Finally this allows us to reuse some artifacts such as our `TargetMachine`
creation, where all our options we used today aren't necessarily supported by
upstream LLVM yet.
My hope is that we can get some experience with this copy/paste in tree and then
eventually upstream some work to LLVM itself to avoid the duplication while
still ensuring our needs are met. Otherwise I fear that maintaining these
bindings may be quite costly over the years with LLVM updates!
projects / rust.git / log