Oliver Middleton [Wed, 27 Dec 2017 23:39:25 +0000 (23:39 +0000)]
rustdoc: Add missing src links for generic impls on trait pages
`implementor2item` would return `None` for generic impls so instead this clones the entire `clean::Item` into the `implementors` map which simplifies some code.
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.
Ed Schouten [Fri, 22 Dec 2017 08:37:02 +0000 (09:37 +0100)]
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/
Scott Abbey [Fri, 22 Dec 2017 03:43:16 +0000 (21:43 -0600)]
Don't try to statically link libstdc++ on FreeBSD
The code inside this conditional will not work on FreeBSD 10+ because
those versions use clang and libc++ rather than libstdc++.
Since FreeBSD comes with libc++ in the base, presumably all 10+ systems
will have it present.
Searching for libstdc++.a will not work if it is not present. As a
result, this would previously have set `LLVM_STATIC_STDCPP=libstdc++.a`,
which isn't a valid path and caused problems later on when building
`librustc_llvm`.
This could possibly be updated in the future to look for `libc++.a` on
FreeBSD, by expanding the code inside the conditional. In one attempt
to run this on x86_64-freebsd, I found that libc++ was not compiled with
PIC, so it failed anyway.
Jed Davis [Sat, 16 Sep 2017 03:14:34 +0000 (21:14 -0600)]
Re-do the FreeBSD cross-builds to use Clang and libc++. Fixes #44433.
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.
bors [Fri, 22 Dec 2017 07:22:33 +0000 (07:22 +0000)]
Auto merge of #46732 - estebank:silence-recovered-blocks, r=petrochenkov
Do not emit type errors on recovered blocks
When a parse error occurs on a block, the parser will recover and create
a block with the statements collected until that point. Now a flag
stating that a recovery has been performed in this block is propagated
so that the type checker knows that the type of the block (which will be
identified as `()`) shouldn't be checked against the expectation to
reduce the amount of irrelevant diagnostic errors shown to the user.
Esteban Küber [Thu, 14 Dec 2017 07:05:49 +0000 (23:05 -0800)]
Do not emit type errors on recovered blocks
When a parse error occurs on a block, the parser will recover and create
a block with the statements collected until that point. Now a flag
stating that a recovery has been performed in this block is propagated
so that the type checker knows that the type of the block (which will be
identified as `()`) shouldn't be checked against the expectation to
reduce the amount of irrelevant diagnostic errors shown to the user.
kennytm [Thu, 21 Dec 2017 18:50:59 +0000 (02:50 +0800)]
Rollup merge of #46918 - alexcrichton:fix-ordering, r=michaelwoerister
rustc: Sort CGUs before merging
This commit fixes some nondeterminism in compilation when using multiple codegen
units. The algorithm for splitting codegen units currently takes the
otherwise-would-be-for-incremental partitioning and then continuously merges the
two smallest codegen units until the desired number of codegen units are
reached.
We want to be sure to merge the same codegen units each time a compilation is
run but there's some subtle reorderings amongst all the items which was causing
this step to be slightly buggy. Notably this step involves sorting codegen units
by size, but if two codegen units had the same size they would appear in
different locations in the list each time.
This commit fixes this issue by sorting codegen units by name before doing the
loop to merge the two smallest. This means that we've got a deterministic
order going in and since we're using a stable sort this should mean that we're
always now getting a deterministic merging of codegen units.
bors [Thu, 21 Dec 2017 20:12:13 +0000 (20:12 +0000)]
Auto merge of #45930 - jplatte:generics_refactoring, r=eddyb
Generics refactoring (groundwork for const generics)
These changes were suggested by @eddyb.
After this change, the `Generics` contain one `Vec` of an enum for the generic parameters, rather than two separate `Vec`s for lifetime and type parameters. Type params and const params will need to be in a shared `Vec` to preserve their ordering, and moving lifetimes into the same `Vec` should simplify the code that processes `Generics`.
kennytm [Thu, 21 Dec 2017 18:50:57 +0000 (02:50 +0800)]
Rollup merge of #46898 - tspiteri:int-overflow-not-underflow, r=steveklabnik
docs: do not call integer overflows as underflows
In the API docs, integer overflow is sometimes called underflow. Underflow is really when the magnitude of a floating-point number is too small so the number underflows to subnormal or zero. With integers it is always overflow, even if the expected result is less than the minimum number that can be represented.
kennytm [Thu, 21 Dec 2017 18:50:53 +0000 (02:50 +0800)]
Rollup merge of #46858 - QuietMisdreavus:external-doc-error, r=estebank
tweaks and fixes for doc(include)
This PR makes a handful of changes around `#[doc(include="file.md")]` (https://github.com/rust-lang/rust/issues/44732):
* Turns errors when loading files into full errors. This matches the original RFC text.
* Makes the `missing_docs` lint check for `#[doc(include="file.md")]` as well as regular `#[doc="text"]` attributes.
* Loads files included by `#[doc(include="file.md")]` into dep-info, mirroring the behavior of `include_str!()` and friends.
* Adds or modifies tests to check for all of these.
kennytm [Thu, 21 Dec 2017 18:50:51 +0000 (02:50 +0800)]
Rollup merge of #46839 - michaelwoerister:faster-span-hashing-2, r=nikomatsakis
incr.comp.: Precompute small hash for filenames to save some work.
For each span we hash the filename of the file it points to. Since filenames can be quite long, especially with absolute paths, this PR pre-computes a hash of the filename and we then only hash the hash.
kennytm [Thu, 21 Dec 2017 18:50:49 +0000 (02:50 +0800)]
Rollup merge of #46814 - varkor:contrib-7, r=alexcrichton
Prevent rustc overwriting input files
If rustc is invoked on a file that would be overwritten by the
compilation, the compilation now fails, to avoid accidental loss. This
resolves #13019. Kudos to @estebank, whose patch I finished off.
kennytm [Thu, 21 Dec 2017 18:50:47 +0000 (02:50 +0800)]
Rollup merge of #46780 - varkor:contrib-5, r=arielb1
Fix ICE when calling non-functions within closures
The visitor for walking function bodies did not previously properly
handle error-cases for function calls. These are now ignored,
preventing the panic. This fixes #46771.
Alex Crichton [Thu, 21 Dec 2017 17:00:55 +0000 (09:00 -0800)]
rustc: Sort CGUs before merging
This commit fixes some nondeterminism in compilation when using multiple codegen
units. The algorithm for splitting codegen units currently takes the
otherwise-would-be-for-incremental partitioning and then continuously merges the
two smallest codegen units until the desired number of codegen units are
reached.
We want to be sure to merge the same codegen units each time a compilation is
run but there's some subtle reorderings amongst all the items which was causing
this step to be slightly buggy. Notably this step involves sorting codegen units
by size, but if two codegen units had the same size they would appear in
different locations in the list each time.
This commit fixes this issue by sorting codegen units by name before doing the
loop to merge the two smallest. This means that we've got a deterministic
order going in and since we're using a stable sort this should mean that we're
always now getting a deterministic merging of codegen units.
bors [Thu, 21 Dec 2017 16:15:16 +0000 (16:15 +0000)]
Auto merge of #46877 - Deewiant:gh46843, r=eddyb
MIR: terminate unreachable blocks in construct_const
Fixes #46843.
#45821 added unreachable blocks in matches, which were terminated in
construct_fn but not in construct_const, causing a panic due to "no
terminator on block" when constants involved matching on enums.
The "unimplemented expression type" error may go away in the future, the
key is that we see the E0015 about using a non-const function and then
don't ICE.
Guillaume Gomez [Thu, 21 Dec 2017 12:18:21 +0000 (13:18 +0100)]
Rollup merge of #46887 - pnkfelix:ensure-activations-are-from-assignments-to-locals, r=arielb1
Ensure separate activations only occur for assignments to locals
Ensure separate activations only occur for assignments to locals, not projections.
Fix #46746.
(I didn't make a regression test because we do not really have a good way to directly express the case that we are trying to catch, because we cannot write MIR directly.)