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?
So in b989428f7d I have set the FreeBSD build to not actually use `LLVM_STATIC_STDCPP`.
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:
b989428f7d/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.
1. Change the return type of `expand_invoc()` and its subroutines to
`Option<Expansion>` from `Expansion`.
2. Return `None` when expanding a derive invocation if the item cannot
have derive on it (in `expand_derive_invoc()`).
Add "Basic Usage" to int min_value and max_value docs
This adds "Basic Usage:" to the docs of `min_value` and `max_value`, which makes it consistent with docs of other integer methods.
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/
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.
cc #47002
r? @aidanhs
Update check::cast::pointer_kind logic to new rustc
Make the match exhaustive, adding handling for anonymous types and
tuple coercions on the way.
Also, exit early when type errors are detected, to avoid error cascades
and the like.
Fixes#33690.
Fixes#46365.
Fixes#46880.
Background
==========
Slices currently have an unstable [`rotate`] method which rotates
elements in the slice to the _left_ N positions. [Here][tracking] is the
tracking issue for this unstable feature.
```rust
let mut a = ['a', 'b' ,'c', 'd', 'e', 'f'];
a.rotate(2);
assert_eq!(a, ['c', 'd', 'e', 'f', 'a', 'b']);
```
Proposal
========
Deprecate the [`rotate`] method and introduce `rotate_left` and
`rotate_right` methods.
```rust
let mut a = ['a', 'b' ,'c', 'd', 'e', 'f'];
a.rotate_left(2);
assert_eq!(a, ['c', 'd', 'e', 'f', 'a', 'b']);
```
```rust
let mut a = ['a', 'b' ,'c', 'd', 'e', 'f'];
a.rotate_right(2);
assert_eq!(a, ['e', 'f', 'a', 'b', 'c', 'd']);
```
Justification
=============
I used this method today for my first time and (probably because I’m a
naive westerner who reads LTR) was surprised when the docs mentioned that
elements get rotated in a left-ward direction. I was in a situation
where I needed to shift elements in a right-ward direction and had to
context switch from the main problem I was working on and think how much
to rotate left in order to accomplish the right-ward rotation I needed.
Ruby’s `Array.rotate` shifts left-ward, Python’s `deque.rotate` shifts
right-ward. Both of their implementations allow passing negative numbers
to shift in the opposite direction respectively.
Introducing `rotate_left` and `rotate_right` would:
- remove ambiguity about direction (alleviating need to read docs 😉)
- make it easier for people who need to rotate right
[`rotate`]: https://doc.rust-lang.org/std/primitive.slice.html#method.rotate
[tracking]: https://github.com/rust-lang/rust/issues/41891
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
r? @arielb1
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.
Closes#45320
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): 5a94a48678/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 🎉
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
```
- Update example in ‘security’ section to use hard links, like the
linked securityvulns.com example.
- Weaken language on symbolic links – indicate behavior is
platform-specific
Fixes https://github.com/rust-lang/rust/issues/43617.
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.
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.
Closes#45320
