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!
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!
bors [Sat, 7 Oct 2017 12:13:28 +0000 (12:13 +0000)]
Auto merge of #44913 - leavehouse:patch-1, r=BurntSushi
Fix TcpStream::local_addr docs example code
The local address's port is not 8080 in this example, that's the remote peer address port. On my machine, the local address is different every time, so I've changed `assert_eq` to only test the IP address
bors [Fri, 6 Oct 2017 15:30:32 +0000 (15:30 +0000)]
Auto merge of #45065 - arielb1:not-correct, r=nikomatsakis
fix logic error in #44269's `prune_cache_value_obligations`
We want to retain obligations that *contain* inference variables, not
obligations that *don't contain* them, in order to fix #43132. Because
of surrounding changes to inference, the ICE doesn't occur in its
original case, but I believe it could still be made to occur on master.
Maybe I should try to write a new test case? Certainly not right now
(I'm mainly trying to get us a beta that we can ship) but maybe before
we land this PR on nightly?
This seems to cause a 10% performance regression in my imprecise
attempt to benchmark item-body checking for #43613, but it's better to
be slow and right than fast and wrong. If we want to recover that, I
think we can change the constrained-type-parameter code to actually
give a list of projections that are important for resolving inference
variables and filter everything else out.
fix logic error in #44269's `prune_cache_value_obligations`
We want to retain obligations that *contain* inference variables, not
obligations that *don't contain* them, in order to fix #43132. Because
of surrounding changes to inference, the ICE doesn't occur in its
original case, but I believe it could still be made to occur on master.
Maybe I should try to write a new test case? Certainly not right now
(I'm mainly trying to get us a beta that we can ship) but maybe before
we land this PR on nightly?
This seems to cause a 10% performance regression in my imprecise
attempt to benchmark item-body checking for #43613, but it's better to
be slow and right than fast and wrong. If we want to recover that, I
think we can change the constrained-type-parameter code to actually
give a list of projections that are important for resolving inference
variables and filter everything else out.
bors [Fri, 6 Oct 2017 12:51:11 +0000 (12:51 +0000)]
Auto merge of #44734 - mchlrhw:wip/hashmap-entry-and-then, r=BurntSushi
Implement `and_modify` on `Entry`
## Motivation
`Entry`s are useful for allowing access to existing values in a map while also allowing default values to be inserted for absent keys. The existing API is similar to that of `Option`, where `or` and `or_with` can be used if the option variant is `None`.
The `Entry` API is, however, missing an equivalent of `Option`'s `and_then` method. If it were present it would be possible to modify an existing entry before calling `or_insert` without resorting to matching on the entry variant.
bors [Fri, 6 Oct 2017 10:20:14 +0000 (10:20 +0000)]
Auto merge of #44965 - oconnor663:res_init_glibc, r=dtolnay
replace libc::res_init with res_init_if_glibc_before_2_26
The previous workaround for gibc's res_init bug is not thread-safe on
other implementations of libc, and it can cause crashes. Use a runtime
check to make sure we only call res_init when we need to, which is also
when it's safe. See https://github.com/rust-lang/rust/issues/43592.
~This PR is returning an InvalidData IO error if the glibc version string fails to parse. We could also have treated that case as "not glibc", and gotten rid of the idea that these functions could return an error. (Though I'm not a huge fan of ignoring error returns from `res_init` in any case.) Do other folks agree with these design choices?~
I'm pretty new to hacking on libstd. Is there an easy way to build a toy rust program against my changes to test this, other than doing an entire `sudo make install` on my system? What's the usual workflow?
bors [Fri, 6 Oct 2017 05:37:43 +0000 (05:37 +0000)]
Auto merge of #44818 - petrochenkov:astymac2, r=jseyfried
Improve resolution of associated types in declarative macros 2.0
Make various identifier comparisons for associated types (and sometimes other associated items) hygienic.
Now declarative macros 2.0 can use `Self::AssocTy`, `TyParam::AssocTy`, `Trait<AssocTy = u8>` where `AssocTy` is an associated type of a trait `Trait` visible from the macro. Also, `Trait` can now be implemented inside the macro and specialization should work properly (fixes https://github.com/rust-lang/rust/pull/40847#issuecomment-310867299).
Jack O'Connor [Sun, 1 Oct 2017 21:42:18 +0000 (17:42 -0400)]
replace libc::res_init with res_init_if_glibc_before_2_26
The previous workaround for gibc's res_init bug is not thread-safe on
other implementations of libc, and it can cause crashes. Use a runtime
check to make sure we only call res_init when we need to, which is also
when it's safe. See https://github.com/rust-lang/rust/issues/43592.
kennytm [Thu, 5 Oct 2017 12:22:30 +0000 (20:22 +0800)]
Rollup merge of #44935 - vitiral:dependencies, r=steveklabnik
Add links to headers in README and CONTRIBUTING
this also adds dependencies to CONTRIBUTING
I'm just getting started building the rust compiler and noticed this information/ability was missing.
It was also missing the gdb dependency for running tests. I pulled the information out of `appveyor.yml` and recommended later than 7.1 because that is what [apt ships](https://packages.ubuntu.com/search?suite=trusty&keywords=gdb). Feel free to tell me something different!
kennytm [Thu, 5 Oct 2017 12:22:29 +0000 (20:22 +0800)]
Rollup merge of #44664 - budziq:contributing_external, r=steveklabnik
Corrected the CONTRIBUTING.md "External Dependencies" section
The "External Dependencies" section is a little outdated.
Please see following comments https://github.com/rust-lang/rust/pull/44567#issuecomment-329797331 https://github.com/rust-lang/rust/pull/44567#issuecomment-329799655 for rationale.
bors [Thu, 5 Oct 2017 10:50:11 +0000 (10:50 +0000)]
Auto merge of #45019 - aidanhs:aphs-no-trans-worker-panic, r=alexcrichton
Don't unwrap work item results as the panic trace is useless
Fixes #43402 now there's no multithreaded panic printouts
Also update a comment
--------
Likely regressed in #43506, where the code was changed to panic in worker threads on error.
Unwrapping gives zero extra information since the stack trace is so short, so we may as well just surface that there was an error and exit the thread properly. Because there are then no multithreaded printouts, I think it should mean the output of the test for #26199 is deterministic and not interleaved (thanks to @philipc https://github.com/rust-lang/rust/issues/43402#issuecomment-333835271 for a hint).
Sadly the output is now:
```
thread '<unnamed>' panicked at 'aborting due to worker thread panic', src/librustc_trans/back/write.rs:1643:20
note: Run with `RUST_BACKTRACE=1` for a backtrace.
error: could not write output to : No such file or directory
error: aborting due to previous error
```
but it's an improvement over the multi-panic situation before.
bors [Wed, 4 Oct 2017 19:14:41 +0000 (19:14 +0000)]
Auto merge of #44901 - michaelwoerister:on-demand-eval, r=nikomatsakis
incr.comp.: Switch to red/green change tracking, remove legacy system.
This PR finally switches incremental compilation to [red/green tracking](https://github.com/rust-lang/rust/issues/42293) and completely removes the legacy dependency graph implementation -- which includes a few quite costly passes that are simply not needed with the new system anymore.
There's still some documentation to be done and there's certainly still lots of optimizing and tuning ahead -- but the foundation for red/green is in place with this PR. This has been in the making for a long time `:)`
r? @nikomatsakis
cc @alexcrichton, @rust-lang/compiler
bors [Wed, 4 Oct 2017 15:14:15 +0000 (15:14 +0000)]
Auto merge of #44890 - nvzqz:str-box-transmute, r=alexcrichton
Remove mem::transmute used in Box<str> conversions
Given that https://github.com/rust-lang/rust/pull/44877 is failing, I decided to make a separate PR. This is done with the same motivation: to avoid `mem::transmute`-ing non `#[repr(C)]` types.
bors [Wed, 4 Oct 2017 03:28:24 +0000 (03:28 +0000)]
Auto merge of #44999 - pnkfelix:mir-borrowck-fix-assert-left-right, r=nikomatsakis
Overlapping borrows can point to different lvalues.
Overlapping borrows can point to different lvalues.
There's always a basis for the overlap, so instead of removing the assert entirely, I instead pass in the prefix that we found and check that it actually is a prefix of both lvalues.
bors [Wed, 4 Oct 2017 00:57:30 +0000 (00:57 +0000)]
Auto merge of #44979 - hinaria:master, r=dtolnay
make `backtrace = false` compile for windows targets.
when building for windows with `backtrace = false`, `libstd` fails to compile because some modules that use items from `sys_common::backtrace::*` are still included, even though those modules aren't used or referenced by anything.
`sys_common::backtrace` doesn't exist when the backtrace feature is turned off.
--
i've also added `#[cfg(feature = "backtrace")]` to various items that exist exclusively to support `mod backtrace` since the compilation would fail since they would be unused in a configuration with backtraces turned off.
bors [Tue, 3 Oct 2017 22:19:40 +0000 (22:19 +0000)]
Auto merge of #44895 - stephaneyfx:master, r=dtolnay
Made `fs::copy` return the length of the main stream
On Windows with the NTFS filesystem, `fs::copy` would return the sum of the
lengths of all streams, which can be different from the length reported by
`metadata` and thus confusing for users unaware of this NTFS peculiarity.
This makes `fs::copy` return the same length `metadata` reports which is the
value it used to return before PR #26751. Note that alternate streams are still
copied; their length is just not included in the returned value.
This change relies on the assumption that the stream with index 1 is always the
main stream in the `CopyFileEx` callback. I could not find any official
document confirming this but empirical testing has shown this to be true,
regardless of whether the alternate stream is created before or after the main
stream.
bors [Tue, 3 Oct 2017 19:38:33 +0000 (19:38 +0000)]
Auto merge of #44949 - QuietMisdreavus:rustdoctest-dirs, r=nikomatsakis
let htmldocck.py check for directories
Since i messed this up during https://github.com/rust-lang/rust/pull/44613, i wanted to codify this into the rustdoc tests to make sure that doesn't happen again.
bors [Tue, 3 Oct 2017 12:18:13 +0000 (12:18 +0000)]
Auto merge of #44896 - qmx:move-resolve-to-librustc, r=arielb1
Move monomorphize::resolve() to librustc
this moves `monomorphize::resolve(..)` to librustc, and re-enables inlining for some trait methods, fixing #44389
@nikomatsakis I've kept the calls to the new `ty::Instance::resolve(....)` always `.unwrap()`-ing for the moment, how/do you want to add more debugging info via `.unwrap_or()` or something like this?
we still have some related `resolve_*` functions on monomorphize, but I wasn't sure moving them was into the scope for this PR too.
Overlapping borrows can point to different lvalues.
There's always a basis for the overlap, so instead of removing the
assert entirely, I instead pass in the prefix that we found and check
that it actually is a prefix of both lvalues.
James Munns [Mon, 2 Oct 2017 13:42:08 +0000 (15:42 +0200)]
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](https://www.kernel.org/doc/Documentation/arm/kernel_user_helpers.txt) which can be used to perform atomic operations. When linked with `libc`, the atomic symbols needed by Rust will be provided, rather than CPU level intrinsics.
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.