…e item

Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com>

Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com>

Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com>

Also modifies the generation script to emit 2018 edition paths.

Following what clang does (https://github.com/llvm/llvm-project/blob/296a80102a9b72c3eda80558fb78a3ed8849b341/clang/lib/Driver/ToolChains/Darwin.cpp#L1661-L1678), allow allow SDKROOT to tell us where the Apple SDK lives so we don't have to invoke xcrun.

Previously we used the executables built the LLVM project but these
executables are difficult to run in a CI environment, they can
accidentally pollute global state, etc. In testing some of the possible
4-core machine environments for Azure this step would frequently cause
issues.

To assuage these future issues and hopefully make builds slightly more
self-contained, this commit changes to install from a tarball instead.
The tarball isn't provided by LLVM itself, but we use the offical LLVM
installer to extract itself and then we pack up the LLVM installation
directory into the tarball.

It is broken and unused

…se drop

…t be non-NULL

…e it is dereferenced

This is test specific to the NLL migrate mode which is irrelevant to -Z polonius.
It can't currently be encoded depending on migrate-mode and NLL/Polonius mode, so the NLL compare-mode also ignores it.

There is no difference between the NLL and Polonius outputs, and it manually tests NLLs.

…mpare mode

This is just a difference from the test construction, it's ignore-compare-mode-nll and manually checks migrate/nll over edition2015/2018.

This failure is because the `migrate2015` and `migrate2018`  revisions are ran with `-Zpolonius`. There is no actual difference in the errors output by NLLs and Polonius.

This is a test about turning the NLL feature gate on, ignored by the NLL compare-mode.

…re mode

Once again, the difference is in the test construction, it is ignored in compare-mode NLL and tested manually with revisions, and fails because the `migrate` revision is ran with `-Zpolonius`. There is no actual difference in the errors output by NLLs and Polonius.

2 of the 3 errors are "fixed by Polonius" 🎉

…Polonius

…r Polonius

…olonius

…or Polonius

Like "call-kills-loans", Polonius didn't know about some `killed` facts.

…ve-fn-1.rs for Polonius

…y loans

…ually check each outcome

Fixing assignments to projections made the Polonius output exactly the same as the NLL one.

This allows the same logic used by `include_X!` macros to be used by
`#[doc(include)]`.

This makes them relative to the containing file instead of the crate
root

Co-Authored-By: gnzlbg <gnzlbg@users.noreply.github.com>

In `configure.py`, using the `o` function creates an enable/disable
boolean setting, and writes `true` or `false` in `config.toml`. However,
rustbuild is expecting to parse a `u32` debuginfo level. We can change
to the `v` function to have the options require a value.

Closes rust-lang#51046
Closes rust-lang#40471

…ibutes

Instead of
```
mod allocator_abi { /* methods */ }
```
we now generate
```
const _: () = { /* methods */ }
```
and use `std_path` for paths referring to standard library entities.

This way we no longer need to generate `use` and `extern crate` imports, and `#[global_allocator]` starts working inside unnamed blocks.

…r=petrochenkov

rustdoc: make #[doc(include)] relative to the containing file

This matches the behavior of other in-source paths like `#[path]` and the `include_X!` macros.

Fixes rust-lang#58373 (comment)
Also addresses rust-lang#44732 (comment)

cc rust-lang#44732

This is still missing a stdsimd change (https://github.com/jonas-schievink/stdsimd/commit/42ed30e0b5fb5e2d11765b5d1e1f36234af85984), so CI will currently fail. I'll land that change once I get initial feedback for this PR.

…=Dylan-DPC

Fix some sanity checks

Update: Changes that made it not to work dropped.

* Fix `building_llvm` in sanity check
  * This was subtly broken: we build LLVM if any of the hosts builds LLVM, and not setting the config meant that LLVM is built for that target. Because of filtering away the targets not configured and the semantics of `Iterator::any`, it currently didn't set the `building_llvm` flag even if we indeed build it.
* Add `swig` sanity check
  * This checks whether there is a `swig` executable needed for LLDB.

allow clippy::unreadable_literal in unicode tables

Also modifies the generation script to emit 2018 edition paths.

…inhabited-subst, r=oli-obk

Take substs into account in `conservative_is_privately_uninhabited`

Add joining slices of slices with a slice separator, not just a single item

rust-lang#27747 (comment)
> It's kinda annoying to be able to join strings with a str (which can have multiple chars), but joining a slice of slices, you can only join with a single element.

This turns out to be fixable, with some possible inference regressions.

# TL;DR

Related trait(s) are unstable and tracked at rust-lang#27747, but the `[T]::join` method that is being extended here is already stable.

Example use of the new insta-stable functionality:

```rust
let nested: Vec<Vec<Foo>> = /* … */;
let separator: &[Foo] = /* … */;  // Previously: could only be a single &Foo
nested.join(separator)
```

Complete API affected by this PR, after changes:

```rust
impl<T> [T] {
    pub fn concat<Item: ?Sized>(&self) -> <Self as Concat<Item>>::Output
        where Self: Concat<Item>
    {
        Concat::concat(self)
    }
    pub fn join<Separator>(&self, sep: Separator) -> <Self as Join<Separator>>::Output
        where Self: Join<Separator>
    {
        Join::join(self, sep)
    }
}

// The `Item` parameter is only useful for the the slice-of-slices impl.
pub trait Concat<Item: ?Sized> {
    type Output;
    fn concat(slice: &Self) -> Self::Output;
}

pub trait Join<Separator> {
    type Output;
    fn join(slice: &Self, sep: Separator) -> Self::Output;
}

impl<T: Clone, V: Borrow<[T]>> Concat<T> for [V] {
    type Output = Vec<T>;
}

impl<T: Clone, V: Borrow<[T]>> Join<&'_ T> for [V] {
    type Output = Vec<T>;
}

// New functionality here!
impl<T: Clone, V: Borrow<[T]>> Join<&'_ [T]> for [V] {
    type Output = Vec<T>;
}

impl<S: Borrow<str>> Concat<str> for [S] {
    type Output = String;
}

impl<S: Borrow<str>> Join<&'_ str> for [S] {
    type Output = String;
}
```

# Details

After rust-lang#62403 but before this PR, the API is:

```rust
impl<T> [T] {
    pub fn concat<Separator: ?Sized>(&self) -> T::Output
        where T: SliceConcat<Separator>
    {
        SliceConcat::concat(self)
    }

    pub fn join<Separator: ?Sized>(&self, sep: &Separator) -> T::Output
        where T: SliceConcat<Separator>
    {
        SliceConcat::join(self, sep)
    }
}

pub trait SliceConcat<Separator: ?Sized>: Sized {
    type Output;
    fn concat(slice: &[Self]) -> Self::Output;
    fn join(slice: &[Self], sep: &Separator) -> Self::Output;
}

impl<T: Clone, V: Borrow<[T]>> SliceConcat<T> for V {
    type Output = Vec<T>;
}

impl<S: Borrow<str>> SliceConcat<str> for S {
    type Output = String;
}
```

By adding a trait impl we should be able to accept a slice of `T` as the separator, as an alternative to a single `T` value.

In a `some_slice.join(some_separator)` call, trait resolution will pick an impl or the other based on the type of `some_separator`. In `some_slice.concat()` however there is no separator, so this call would become ambiguous. Some regression in type inference or trait resolution may be acceptable on principle, but requiring a turbofish for every single call to `concat` isn’t great.

The solution to that is splitting the `SliceConcat` trait into two `Concat` and `Join` traits, one for each eponymous method. Only `Join` would gain a new impl, so that `some_slice.concat()` would not become ambiguous.

Now, at the trait level the `Concat` trait does not need a `Separator` parameter anymore. However, simply removing it causes one of the impls not to be accepted anymore:

```rust
error[E0207]: the type parameter `T` is not constrained by the impl trait, self type, or predicates
  --> src/liballoc/slice.rs:608:6
    |
608 | impl<T: Clone, V: Borrow<[T]>> Concat for [V] {
    |      ^ unconstrained type parameter
```

This makes sense: if `[V]::concat` is a method that is itself not generic, then its return type (which is the `Concat::Output` associated type) needs to be determined based on solely `V`. And although there is no such type in the standard library, there is nothing stopping another crate from defining a `V` type that implements both `Borrow<[Foo]>` and `Borrow<[Bar]>`. It might not be a good idea, but it’s possible. Both would apply here, and there would be no way to determine `T`.

This could be a warning sign that this API is too generic. Perhaps we’d be better off having one less type variable, and only implement `Concat for [&'_ [T]]` and `Concat for [Vec<T>]` etc. However this aspect of `[V]::concat` is already stable, so we’re stuck with it.

The solution is to keep a dummy type parameter on the `Concat` trait. That way, if a type has multiple `Borrow<[_]>` impls, it’ll end up with multiple corresponding `Concat<_>` impls.

In `impl<S: Borrow<str>> Concat<str> for [S]`, the second occurrence of `str` is not meaningful. It could be any type. As long as there is only once such type with an applicable impl, trait resolution will be appeased without demanding turbofishes.

# Joining strings with `char`

For symmetry I also tried adding this impl (because why not):

```rust
impl<S: Borrow<str>> Join<char> for [S] {
    type Output = String;
}
```

This immediately caused an inference regression in a dependency of rustc:

```rust
error[E0277]: the trait bound `std::string::String: std::borrow::Borrow<[std::string::String]>` is not satisfied
   --> /home/simon/.cargo/registry/src/git.luolix.top-1ecc6299db9ec823/getopts-0.2.19/src/lib.rs:595:37
    |
595 |             row.push_str(&desc_rows.join(&desc_sep));
    |                                     ^^^^ the trait `std::borrow::Borrow<[std::string::String]>` is not implemented for `std::string::String`
    |
    = help: the following implementations were found:
              <std::string::String as std::borrow::Borrow<str>>
    = note: required because of the requirements on the impl of `std::slice::Join<&std::string::String>` for `[std::string::String]`
```

In the context of this code, two facts are known:

* `desc_rows` is a `Vec<String>`
* `desc_sep` is a `String`

Previously the first fact alone reduces the resolution of `join` to only one solution, where its argument it expected to be `&str`. Then, `&String` is coerced to `&str`.

With the new `Join` impl, the first fact leavs two applicable impls where the separator can be either `&str` or `char`. But `&String` is neither of these things. It appears that possible coercions are not accounted for, in the search for a solution in trait resolution.

I have not included this new impl in this PR. It’s still possible to add later, but the `getopts` breakage does not need to block the rest of the PR. And the functionality easy for end-user to duplicate: `slice_of_strings.join(&*char_separator.encode_utf8(&mut [0_u8, 4]))`

The `&*` part of that last code snippet is another case of the same issue: `encode_utf8` returns `&mut str` which can be coerced to `&str`, but isn’t when trait resolution is ambiguous.

Turn `#[global_allocator]` into a regular attribute macro

It was a 99% macro with exception of some diagnostic details.

As a result of the change, `#[global_allocator]` now works in nested modules and even in nameless blocks.

Fixes rust-lang#44113
Fixes rust-lang#58072

…lexcrichton

Remove support for -Zlower-128bit-ops

It is broken and unused

cc rust-lang#58969

blocked rust-lang/compiler-builtins#302 (removes definitions of the lang items removed in this PR)

r? @alexcrichton

Improve some pointer-related documentation

Disable d32 on armv6 hf targets

We already do this on armv7 targets. It seems that this now gets enabled by default if '+vfp2` is specified, so disable it explicitly.

Hopefully fixes rust-lang#62841.

r? @alexcrichton

Initialize the MSP430 AsmParser

Hopefully fixes rust-lang#59077.

r? @alexcrichton

…isambiguation, r=estebank

Add method disambiguation help for trait implementation

Closes rust-lang#51046
Closes rust-lang#40471

…rgo, r=sfackler

Use match ergonomics in Condvar documentation

Documentation was written before match ergonomics was merged. See rust-lang#62857.

In short, replaces

```rust
let &(ref lock, ref cvar) = &*pair;
```

with

```rust
let (lock, cvar) = &*pair
```

in the docs of `std::sync::Condvar`.

… r=alexcrichton

Add binary dependencies to dep-info files

I'm not sure about the lack of incremental-tracking here, but since I'm pretty sure this runs on every compile anyway it might not matter? If there's a better place/way to get at the information I want, I'm happy to refactor the code to match.

r? @alexcrichton

Polonius: fix some cases of `killed` fact generation, and most of the `ui` test suite

Since basic Polonius functionality was re-enabled by @matthewjasper in rust-lang#54468, some tests were still failing in the polonius compare-mode.

This PR fixes all but one test in the `ui` suite by:
- fixing some bugs in the fact generation code, related to the `killed` relation: Polonius would incorrectly reject some NLL-accepted code, because of these missing `killed` facts.
- ignoring some tests in the polonius compare-mode: a lot of those manually test the NLL or migrate mode, and the failures were mostly artifacts of the test revisions, e.g. that `-Z polonius` requires full NLLs. Some others were also both failing with NLL and succeeding with Polonius, which we can't encode in tests at the moment.
- blessing the output of some tests: whenever Polonius and NLL have basically the same errors, except for diagnostics differences, the Polonius output is blessed. Whenever we've advanced into a less experimental phase, we'll want to revisit these cases (much like we did on the NLL test suite last year) to specifically work on diagnostics.

Fact generation changes:
- we now kill loans on the destination place of `Call` terminators
- we now kill loans on the locals destroyed by `StorageDead`
- we now also handle assignments to projections: killing the loans on a either a deref-ed local, or the ones whose `borrowed_place` conflicts with the current place.

One failing test remains: an overflow during fact generation, on a case of polymorphic recursion (and which I'll continue investigating later).

This adds some tests for the fact generation changes, with some simple Polonius cases similar to the existing smoke tests, but also for some cases encountered in the wild (in the `rand` crate for example).

A more detailed write-up is available [here](https://hackmd.io/CjYB0fs4Q9CweyeTdKWyEg?view) with an explanation for each test failure, the steps taken to resolve it (as a commit in the current PR), NLL and Polonius outputs (and diff), etc.

Since they've worked on this before, and we've discussed some of these failures together:

r? @matthewjasper

…r=pietroalbini

ci: Install clang on Windows through tarballs

Previously we used the executables built the LLVM project but these
executables are difficult to run in a CI environment, they can
accidentally pollute global state, etc. In testing some of the possible
4-core machine environments for Azure this step would frequently cause
issues.

To assuage these future issues and hopefully make builds slightly more
self-contained, this commit changes to install from a tarball instead.
The tarball isn't provided by LLVM itself, but we use the offical LLVM
installer to extract itself and then we pack up the LLVM installation
directory into the tarball.

Add riscv32i-unknown-none-elf target

This target is likely to be useful for constrained FPGA soft-cores, such as picorv32 and HeavyX.

…xcrichton

add support for hexagon-unknown-linux-musl

Don't link mcjit/interpreter LLVM components

We don't use these. Drop related unused ExecutionEngine header uses.

As some drive-by cleanup drop the unused `EnableARMEHABI` global and remove an outdated version check for the hexagon component.

r? @alexcrichton

cleanup: Remove `extern crate serialize as rustc_serialize`s

Support SDKROOT env var on iOS

Following what clang does (https://github.com/llvm/llvm-project/blob/296a80102a9b72c3eda80558fb78a3ed8849b341/clang/lib/Driver/ToolChains/Darwin.cpp#L1661-L1678), allow allow SDKROOT to tell us where the Apple SDK lives so we don't have to invoke xcrun.

Replaces rust-lang#62551.

…ulacrum

Require a value for configure --debuginfo-level

In `configure.py`, using the `o` function creates an enable/disable
boolean setting, and writes `true` or `false` in `config.toml`. However,
rustbuild is expecting to parse a `u32` debuginfo level. We can change
to the `v` function to have the options require a value.

Rollup of 13 pull requests

Successful merges:

 - rust-lang#60938 (rustdoc: make #[doc(include)] relative to the containing file)
 - rust-lang#61890 (Fix some sanity checks)
 - rust-lang#62084 (allow clippy::unreadable_literal in unicode tables)
 - rust-lang#62261 (Take substs into account in `conservative_is_privately_uninhabited`)
 - rust-lang#62528 (Add joining slices of slices with a slice separator, not just a single item)
 - rust-lang#62735 (Turn `#[global_allocator]` into a regular attribute macro)
 - rust-lang#62801 (Remove support for -Zlower-128bit-ops)
 - rust-lang#62808 (Revert "Disable stack probing for gnux32.")
 - rust-lang#62822 (Improve some pointer-related documentation)
 - rust-lang#62904 (Disable d32 on armv6 hf targets)
 - rust-lang#62907 (Initialize the MSP430 AsmParser)
 - rust-lang#62921 (Add method disambiguation help for trait implementation)
 - rust-lang#62942 (Use match ergonomics in Condvar documentation)

Failed merges:

r? @ghost