Permalink
Commits on Oct 8, 2017
  1. Auto merge of #45030 - raggi:zircon-handle-t, r=alexcrichton

    bors committed Oct 8, 2017
    zircon: the type of zx_handle_t is now unsigned
    
    This is a kernel ABI change that landed today. I noticed some other ABI
    issues and have left a note to cleanup once they are better defined.
  2. Auto merge of #45016 - pnkfelix:mir-borrowck-gather-and-signal-move-e…

    bors committed Oct 8, 2017
    …rrors, 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.
    
    Fix #44830
  3. Auto merge of #45020 - MaloJaffre:needs-test, r=alexcrichton

    bors committed Oct 8, 2017
    Fix some E-needstest issues.
    
    Also ignore `attr-on-trait` test on stage-1 to keep `./x.py test --stage 1` successful.
    
    Fixes #30355.
    Fixes #33241.
    Fixes #36400.
    Fixes #37887.
    Fixes #44578.
  4. Auto merge of #45012 - Gankro:noalias, r=arielb1

    bors committed Oct 8, 2017
    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).
  5. Auto merge of #45001 - bgermann:master, r=alexcrichton

    bors committed Oct 8, 2017
    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.
  6. Auto merge of #45100 - kennytm:rollup, r=kennytm

    bors committed Oct 8, 2017
    Rollup of 10 pull requests
    
    - Successful merges: #45018, #45042, #45052, #45053, #45058, #45060, #45081, #45083, #45090, #45094
    - Failed merges:
  7. Rollup merge of #45094 - japaric:strict-align, r=alexcrichton

    kennytm committed Oct 8, 2017
    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.
    
    closes #44538
    r? @alexcrichton
  8. Rollup merge of #45090 - rust-lang:petrochenkov-patch-1, r=alexcrichton

    kennytm committed Oct 8, 2017
    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 - rust-lang#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).
    
    r? @alexcrichton
  9. Rollup merge of #45083 - fhartwig:slice-read-to-end, r=bluss

    kennytm committed Oct 8, 2017
    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  rust-lang#44819 (I think extending this to `Take<&[u8]> `would require specialization)
  10. Rollup merge of #45081 - tamird:fmt-cleanup, r=alexcrichton

    kennytm committed Oct 8, 2017
    fmt: misc cleanup
  11. Rollup merge of #45060 - topecongiro:semi-in-local-span, r=petrochenkov

    kennytm committed Oct 8, 2017
    Add a semicolon to span for ast::Local
  12. Rollup merge of #45058 - hunteke:fix_rustc_private_typo_2017Oct, r=sh…

    kennytm committed Oct 8, 2017
    …epmaster
    
    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?  ;-)
  13. Rollup merge of #45053 - GuillaumeGomez:atomicbool-doc, r=QuietMisdre…

    kennytm committed Oct 8, 2017
    …avus
    
    Add missing links for AtomicBool
    
    r? @rust-lang/docs
  14. Rollup merge of #45052 - steveklabnik:gh44105, r=dtolnay

    kennytm committed Oct 8, 2017
    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.
    
    Fixes #44105
  15. Rollup merge of #45042 - brennie:brennie/fmt-trait-summaries, r=steve…

    kennytm committed Oct 8, 2017
    …klabnik
    
    Update trait summaries for std::fmt
    
    This patch is part of #29355.
    
    r? @steveklabnik
  16. Rollup merge of #45018 - michaelwoerister:fix-dep-node-debug-recursio…

    kennytm committed Oct 8, 2017
    …n, r=eddyb
    
    incr.comp.: Fix infinite recursion in Debug implementation of DepNode
    
    Small bug fix. Depends on #44901 to land first.
  17. Auto merge of #44983 - vitiral:dirty_clean_groups, r=michaelwoerister

    bors committed Oct 8, 2017
    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.
  18. Auto merge of #44978 - jamesmunns:armv5te-os-atomics, r=alexcrichton

    bors committed Oct 8, 2017
    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};
    
    #[no_mangle]
    pub extern fn foo(a: &AtomicIsize) -> isize {
    
        a.fetch_add(1, Ordering::SeqCst)
    }
    ```
    
    ```
    Disassembly of section .text.foo:
    
    00000000 <foo>:
       0:	e92d4800 	push	{fp, lr}
       4:	e3a01001 	mov	r1, #1
       8:	ebfffffe 	bl	0 <__sync_fetch_and_add_4>
       c:	e8bd8800 	pop	{fp, pc}
    ```
    
    Which in turn is provided by `libgcc.a`, which has code which looks like this:
    
    ```
    Disassembly of section .text:
    
    00000000 <__sync_fetch_and_add_4>:
           0:	e92d40f8 	push	{r3, r4, r5, r6, r7, lr}
           4:	e1a05000 	mov	r5, r0
           8:	e1a07001 	mov	r7, r1
           c:	e59f6028 	ldr	r6, [pc, #40]	; 3c <__sync_fetch_and_add_4+0x3c>
          10:	e5954000 	ldr	r4, [r5]
          14:	e1a02005 	mov	r2, r5
          18:	e1a00004 	mov	r0, r4
          1c:	e0841007 	add	r1, r4, r7
          20:	e1a0e00f 	mov	lr, pc
          24:	e12fff16 	bx	r6
          28:	e3500000 	cmp	r0, #0
          2c:	1afffff7 	bne	10 <__sync_fetch_and_add_4+0x10>
          30:	e1a00004 	mov	r0, r4
          34:	e8bd40f8 	pop	{r3, r4, r5, r6, r7, lr}
          38:	e12fff1e 	bx	lr
          3c:	ffff0fc0 	.word	0xffff0fc0
    ```
    
    Where you can see the reference to `0xffff0fc0`, which is provided by the [user space helpers].
Commits on Oct 7, 2017
  1. Auto merge of #44841 - alexcrichton:thinlto, r=michaelwoerister

    bors committed Oct 7, 2017
    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!
  2. Add read_to_end implementation to &[u8]'s Read impl

    fhartwig committed Oct 7, 2017
    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.
  3. Auto merge of #44892 - GuillaumeGomez:fnty-args-rustdoc, r=eddyb

    bors committed Oct 7, 2017
    Fnty args rustdoc
    
    Fixes #44570.
    
    cc @QuietMisdreavus
    cc @rust-lang/dev-tools
    
    Considering the impact on the `hir` libs, I'll put @eddyb as reviewer.
    
    r? @eddyb
  4. enable strict alignment (+strict-align) on ARMv6

    japaric committed Oct 7, 2017
    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.
  5. rustc: Implement ThinLTO

    alexcrichton committed Jul 23, 2017
    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!
  6. Auto merge of #44913 - leavehouse:patch-1, r=BurntSushi

    bors committed Oct 7, 2017
    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
  7. Add names to BareFnTy

    GuillaumeGomez committed Sep 26, 2017
  8. fmt: DRY

    tamird committed Oct 7, 2017
  9. Auto merge of #44860 - kennytm:fix-44731, r=alexcrichton

    bors committed Oct 7, 2017
    Fix issue #44731.
    
    Also excludes `impl Trait` from everybody_loops if it appears in the path.
    
    Fixes #44731.
  10. Auto merge of #44515 - tamird:clean-shims, r=alexcrichton

    bors committed Oct 7, 2017
    {compiler-builtins,libc} shim cleanup
    
    ~~Depends on rust-lang/libc#764; opening early for feedback.~~ r? @alexcrichton
  11. Auto merge of #44614 - tschottdorf:pat_adjustments, r=nikomatsakis

    bors committed Oct 7, 2017
    implement pattern-binding-modes RFC
    
    See the [RFC] and [tracking issue].
    
    [tracking issue]: #42640
    [RFC]: https://github.com/rust-lang/rfcs/blob/491e0af/text/2005-match-ergonomics.md
Commits on Oct 6, 2017