bors [Wed, 27 Dec 2017 22:39:00 +0000 (22:39 +0000)]
Auto merge of #47016 - malbarbo:dist-armv5te, r=alexcrichton
Add dist builder for armv5te-unknown-linux-gnueabi (again)
The dist builder was first add in https://github.com/rust-lang/rust/pull/46498 and later remove in https://github.com/rust-lang/rust/pull/46498 because of https://github.com/rust-lang/rust/issues/46822.
https://github.com/rust-lang/rust/issues/46822 seems to be fixed now (I and @green-s have [tested](https://github.com/rust-lang/rust/pull/46498#issuecomment-353901216) it).
bors [Wed, 27 Dec 2017 12:54:25 +0000 (12:54 +0000)]
Auto merge of #47009 - eddyb:issue-46855, r=arielb1
rustc_trans: support ZST indexing involving uninhabited types.
Fixes #46855 in a minimal way. I decided against supporting non-memory `Rvalue::Len` in this PR (see https://github.com/rust-lang/rust/issues/46855#issuecomment-352965807), as `PlaceContext::Inspect` is also used for `Rvalue::Discriminant`.
bors [Wed, 27 Dec 2017 10:19:43 +0000 (10:19 +0000)]
Auto merge of #47007 - eddyb:issue-46897, r=arielb1
rustc: don't use union layouts for tagged union enums.
Fixes #46897, fixes #43517 (AFAICT from the testcases).
This PR doesn't add any testcases, we should try to at least get perf ones (cc @Mark-Simulacrum).
I couldn't find an example in those issues where the choice of LLVM array vs struct (with N identical fields) for padding filler types is still needed, *on top of* this change, to prevent excessive LLVM sinking.
bors [Tue, 26 Dec 2017 20:47:31 +0000 (20:47 +0000)]
Auto merge of #46975 - matthewjasper:mir-moveck-asm, r=arielb1
[MIR Borrowck] Moveck inline asm statements
Closes #45695
New behavior:
* Input operands to `asm!` are moved, direct output operands are initialized.
* Direct, non-read-write outputs match the assignment changes in #46752 (Shallow writes, end borrows).
bors [Tue, 26 Dec 2017 18:03:00 +0000 (18:03 +0000)]
Auto merge of #46554 - kennytm:45861-step-4-5-6-7-upload-test-result-and-remove-toolstate-toml, r=alexcrichton
[auto-toolstate] Upload the toolstate result to an external git repository, and removes BuildExpectation
This PR consists of 3 commits.
1. (Steps 4–6) The `toolstate.json` output previously collected is now pushed to the https://github.com/rust-lang-nursery/rust-toolstate repository.
2. (Step 7) Revert commit ab018c7, thus removing all traces of `BuildExpectation` and `toolstate.toml`.
3. (Step 8) Adjust CONTRIBUTION.md for the new procedure.
These are the last steps of #45861. After this PR, the toolstate will be automatically computed and published to https://rust-lang-nursery.github.io/rust-toolstate/. There is no need to manage toolstate.toml again.
This also adds the `ToolBuild::is_ext_tool` field to replace the previous
`ToolBuild::expectation` field, to indicate whether a build-failure of
certain tool is essential.
bors [Tue, 26 Dec 2017 11:16:12 +0000 (11:16 +0000)]
Auto merge of #46941 - ScottAbbey:freebsd-build-update, r=alexcrichton
Re-do the FreeBSD cross-builds to use Clang and libc++. Fixes #44433
Reviving #45077, from @jld:
> The main goal here is to use FreeBSD's normal libc++, instead of
> statically linking the libstdc++ packaged with GCC, because that
> libstdc++ has bugs that cause rustc to deadlock inside LLVM.
>
> But the easiest way to use libc++ is to switch the build from GCC to
> Clang, and the Clang package in the Ubuntu image already knows how to
> cross-compile (given a sysroot and preferably cross-binutils), so the
> toolchain script now uses that instead of building a custom compiler.
>
> This also de-duplicates the build-toolchain.sh script.
#45077 was close but didn't quite make it. I rebased @jld's work off the current `master` and started with that.
I was able to determine that this Travis error (https://github.com/rust-lang/rust/pull/45077#issuecomment-336029862) was ultimately caused by `src/librustc_llvm/build.rs` attempting to follow a wrong value in `LLVM_STATIC_STDCPP` (https://github.com/rust-lang/rust/pull/45077#issuecomment-352639456).
I looked at the downstream port for FreeBSD (https://svnweb.freebsd.org/ports/head/lang/rust/) and it seems like they do not use `--enable-llvm-static-stdcpp`.
Since `libc++` is included in the FreeBSD 10+ base system, we don't need to statically link it either?
I was able to run `./src/ci/docker/run.sh` with both `dist-i686-freebsd` and `dist-x86_64-freebsd` successfully and in about 1 minute of testing it seemed like the dist-x86_64-freebsd results worked on a FreeBSD 11 system.
It should fix #44433, which seems to be affecting many potential users. Also FreeBSD users should be able to `./x.py build` which should help anyone who wants to upstream fixes for FreeBSD.
Questions:
Does this approach seem to be the right way to go? Do we actually really want to statically link `libc++`? (I tried that here, but it ultimately ran into a roadblock on x86_64: https://github.com/rust-lang/rust/pull/45077#issuecomment-353293414)
Can we rewrite the comment here to be more clear about why some systems aren't going to actually use this option:
https://github.com/rust-lang/rust/blob/b989428f7dec7b52d68bed6a21e9b5b0a8086267/src/bootstrap/compile.rs#L550-L553
How does this affect users of older FreeBSD systems? It seemed like no one was complaining about using a 10.3 base version in the thread for #45077. FreeBSD seems to only officially support 10.3, 10.4, and 11.x right now, do we have to consider older users? The `libc++` stuff came in for FreeBSD 10, older FreeBSD used `libstdc++`.
Looks like @alexcrichton was leading the discussion on the previous issue:
r? @alexcrichton
Let me know what I can do to help get this through.
kennytm [Tue, 26 Dec 2017 07:18:58 +0000 (15:18 +0800)]
Rollup merge of #46940 - EdSchouten:cloudabi, r=alexcrichton
Add support for CloudABI targets to the rustc backend.
CloudABI is a sandboxed UNIX-like runtime environment. It is a
programming environment that uses a capability-based security model. In
practice this means that many POSIX interfaces are present, except for
ones that try to access resources out of thin air. For example, open()
is gone, but openat() is present.
Right now I'm at the point where I can compile very basic CloudABI
applications on all four supported architectures (ARM and x86, 32 and 64
bits). The next step will be to get libstd to work. Patches for that are
outside the scope of this change.
More info: https://nuxi.nl/cloudabi/ https://github.com/NuxiNL/cloudlibc/
kennytm [Tue, 26 Dec 2017 07:18:57 +0000 (15:18 +0800)]
Rollup merge of #46939 - davidalber:code-of-conduct-mod-team-link, r=kennytm
Fixing Rust Moderation Team link in Code of Conduct
The [Code of Conduct](https://github.com/rust-lang/rust/blob/master/CODE_OF_CONDUCT.md) has two broken links to the Rust Moderation Team.
- The current link is https://github.com/rust-lang/rust/blob/master/team.html#Moderation. That happened because the link is relative.
- The link in this PR is https://www.rust-lang.org/team.html#Moderation-team. Note: at the moment this is redirected client-side to a language-specific page and loses the fragment identifier. rust-lang/rust-www#992 aims to correct that.
bors [Tue, 26 Dec 2017 05:46:11 +0000 (05:46 +0000)]
Auto merge of #47000 - kennytm:follow-up-46924, r=arielb1
Follow up to #46924, fix massive spurious failure when starting docker
It seems using `fe80::/64` causes `docker start` to fail with "Address already in use". Try to change to a unique local address range instead.
`fe80::/64` is a link-local address (similar to `169.254.0.0/16` in IPv4). Let's try to use a random "private network" address to see whether that fixes things.
bors [Mon, 25 Dec 2017 04:55:57 +0000 (04:55 +0000)]
Auto merge of #46914 - mikeyhew:raw_pointer_self, r=arielb1
Convert warning about `*const _` to a future-compat lint
#46664 was merged before I could convert the soft warning about method lookup on `*const _` into a future-compatibility lint. This PR makes that change.
fixes #46837
tracking issue for the future-compatibility lint: #46906
bors [Mon, 25 Dec 2017 02:14:35 +0000 (02:14 +0000)]
Auto merge of #46910 - alexcrichton:thinlto-default, r=michaelwoerister
rustc: Set release mode cgus to 16 by default
This commit is the next attempt to enable multiple codegen units by default in
release mode, getting some of those sweet, sweet parallelism wins by running
codegen in parallel. Performance should not be lost due to ThinLTO being on by
default as well.
bors [Sun, 24 Dec 2017 23:35:19 +0000 (23:35 +0000)]
Auto merge of #46899 - m4b:linkage_name_equals_symbol_name, r=michaelwoerister
Set the dwarf linkage_name to the mangled name
ref #46453
@michaelwoerister or anyone else who knows, i'm not sure if this is the correct instance to pass here (or how to get the correct one precisely): https://github.com//m4b/rust/blob/5a94a48678ec0a20ea6a63a783e63546bf9459b1/src/librustc_trans/debuginfo/namespace.rs#L36
So don't merge this yet, I'd like to learn about correct instance first; however, I think this already fixes a bunch of weirdness i'm seeing debugging from time to time, not to mention backtraces in gdb via `bt` are now ~readable~ meaningful :tada:
E.g.:
new:
```
(gdb) bt
#0 <inline::Foo as core::convert::From<()>>::from () at /home/m4b/tmp/bad_debug/inline.rs:11
#1 0x000055555555a35d in inline::deadbeef () at /home/m4b/tmp/bad_debug/inline.rs:16
#2 0x000055555555a380 in inline::main () at /home/m4b/tmp/bad_debug/inline.rs:20
```
old:
```
(gdb) bt
#0 inline::{{impl}}::from () at /home/m4b/tmp/bad_debug/inline.rs:11
#1 0x000055555555b0ed in inline::deadbeef () at /home/m4b/tmp/bad_debug/inline.rs:16
#2 0x000055555555b120 in inline::main () at /home/m4b/tmp/bad_debug/inline.rs:20
```
bors [Sun, 24 Dec 2017 07:34:13 +0000 (07:34 +0000)]
Auto merge of #46888 - cramertj:nested-impl-trait-error, r=nikomatsakis
Add a feature gate for nested uses of `impl Trait`
This allows us to delay stabilization of nested `impl Trait` until we have a plan to solve the problem posed [here](https://github.com/rust-lang/rust/issues/34511#issuecomment-350715858).
bors [Sun, 24 Dec 2017 02:42:15 +0000 (02:42 +0000)]
Auto merge of #46833 - diwic:7c-abort-ffi, r=arielb1
Prevent unwinding past FFI boundaries
Second attempt to write a patch to solve this.
r? @nikomatsakis
~~So, my biggest issue with this patch is the way the patch determines *what* functions should have an abort landing pad (in `construct_fn`). I would ideally have this code match [src/librustc_trans/callee.rs::get_fn](https://github.com/rust-lang/rust/blob/master/src/librustc_trans/callee.rs#L107-L115) but couldn't find an id that returns true for `is_foreign_item`. Also tried `tcx.has_attr("unwind")` with no luck.~~ FIXED
Other issues:
* llvm.trap is an SIGILL on amd64. Ideally we could use panic-abort's version of aborting which is nicer but we don't want to depend on that library...
* ~~Mir inlining is a stub currently.~~ FIXED (no-op)
Also, when reviewing please take into account that I'm new to the code and only partially know what I'm doing... and that I've mostly made made matches on `TerminatorKind::Abort` match either `TerminatorKind::Resume` or `TerminatorKind::Unreachable` based on what looked best.
Alex Crichton [Thu, 21 Dec 2017 15:03:16 +0000 (07:03 -0800)]
rustc: Set release mode cgus to 16 by default
This commit is the next attempt to enable multiple codegen units by default in
release mode, getting some of those sweet, sweet parallelism wins by running
codegen in parallel. Performance should not be lost due to ThinLTO being on by
default as well.