Old implementation called the assembler once per crate, but we need to call
it for each object file instead, because a single crate can now have more
than one object file.

This patch fixes issue rust-lang#45836 (Can't compile core for msp430 in release mode)

This addresses the concern of rust-lang#47316 by estimating CGU size based on
the size of its MIR. Looking at the size estimate differences for a
small selection of crates, this heuristic produces different orderings,
which should more accurately reflect optimisation time.

Fixes rust-lang#47316.

Also a little bit of clean up.

Arrays of uninhabited types were considered to also be uninhabited if
their length had not been evaluated, causing unsoundness.

Unstable sort was added recently, and the code that is being modified is 3 years old. As quicksort doesn't allocate it will likely perform as well as, or better than linear search.

It turns out that this *can* happen after all, if the region is only
used in projections from the input types.

…as key.

Create the concept of an `StructuredDiagnostic` that is self-contained
with enough knowledge of all variables to create a `DiagnosticBuilder`,
including different possible versions (one line output and expanded
explanations).

We needed to manually added the `DW_OP_deref` ourselves in earlier LLVM,
but starting with [D31439] in LLVM 5, it appears that LLVM will always
handle this itself.  When we were still adding this manually, the
resulting `.debug_loc` had too many derefs, and this failed test
`debuginfo/by-value-self-argument-in-trait-impl.rs`.

[D31439]: https://reviews.llvm.org/D31439

Fixes rust-lang#47611.
cc @alexcrichton
r? @michaelwoerister

This commit primarily adds the ability to control what kind of LTO happens when
rustc performs LTO, namely allowing values to be specified to the `-C lto`
option, such as `-C lto=thin` and `-C lto=fat`. (where "fat" is the previous
kind of LTO, throw everything in one giant module)

Along the way this also refactors a number of fields which store information
about whether LTO/ThinLTO are enabled to unify them all into one field through
which everything is dispatched, hopefully removing a number of special cases
throughout.

This is intended to help mitigate rust-lang#47409 but will require a backport as well,
and this would unfortunately need to be an otherwise insta-stable option.

This currently only supports a limited subset of the full compilation,
but is likely 90% of what people will want and is possible without
building a full compiler (i.e., running LLVM). In theory, this means
that contributors who don't want to build LLVM now have an easy way to
compile locally, though running tests won't work.

LLVM has since removed the `CodeModel::Default` enum value in favor of an
`Optional` implementationg throughout LLVM. Let's mirror the same change in Rust
and update the various bindings we call accordingly.

Removed in llvm-mirror/llvm@9aafb854c

Just bog-standard compile error fixed by adding some new header files

Looks like they did some refactoring of flags in the backend and this should
catch us up! The "unsafe algebra" boolean has been split into a number of
boolean flags for various operations, and this updates to use the `setFast`
function which should hopefully have the same behavior as before.

This was updated in llvm-mirror/llvm@00e900afd

It looks like LLVM also removed it in llvm-mirror/llvm@f45adc29d in favor of the
name "GNU64". This was added in the thought that we'd need such a variant when
adding mips64 support but we ended up not needing it! For now let's just
removing the various support on the Rust side of things.

Updated in llvm-mirror/llvm@203c90ba this function now just returns an `Error`,
so this updates the C++ bindings accordingly

The comment for why cloning exists doesn't actually apply for wasm today and
apparently cloning is causing subtle bugs in LLVM, so let's just avoid it
altogether. More specifically after we emit the assembly for the wasm target we
don't actually use the module again, so there's no need to keep both around.

This seemed to be causing some scary verifier assertions in LLVM which seemed to
be uncovered by presumably (?) buggy behavior. Let's just avoid it for now and
make the wasm target slightly more lean in the process.

Looks like the clang with 16.04 fails to compile LLVM 6, but it looks like clang
in 18.04 can indeed compile LLVM 6.

No sense of urgency, just wanted to make sure we don't lag too far behind!

…ichaelwoerister

Add CGU size heuristic for partitioning

This addresses the concern of rust-lang#47316 by estimating CGU size based on
the size of its MIR. Looking at the size estimate differences for a
small selection of crates, this heuristic produces different orderings,
which should more accurately reflect optimisation time. (Fixes rust-lang#47316.)

r? @michaelwoerister

rustc_trans: take into account primitives larger than 8 bytes.

Fixes rust-lang#38763 by marking all "eightbytes" covered by a primitive appropriately, not just the first.

rustc_trans: ignore trailing padding larger than 8 bytes.

Fixes rust-lang#45662 by ignoring a missing second register component, as it could be entirely padding.

Fix no_integrated_as option to work with new codegen architecture.

Old implementation called the assembler once per crate, but we need to call
it for each object file instead, because a single crate can now have more
than one object file.

This patch fixes issue rust-lang#45836 (Can't compile core for msp430 in release mode)

This change can be tested on x86_64 using
```sh
export RUSTFLAGS="-C no_integrated_as -C save_temps"
```

r? @alexcrichton
cc @japaric

…alexcrichton

Add ./x.py check src/{libstd,libtest,librustc}

This currently only supports a limited subset of the full compilation,
but is likely 90% of what people will want and is possible without
building a full compiler (and also building LLVM). In theory, this means
that contributors who don't want to build LLVM now have an easy way to
compile locally, though running tests won't work.

AST/HIR: Add a separate structure for labels

…, r=cramertj

track recursion limit when expanding existential impl trait

r? @cramertj

Fix type inhabitedness check for arrays

Arrays of uninhabited types were considered to also be uninhabited if
their length had not been evaluated, causing unsoundness.

Fixes rust-lang#47563.

r? @eddyb

This commit changes the ABI of SIMD types in the "Rust" ABI to unconditionally
be passed via pointers instead of being passed as immediates. This should fix a
longstanding issue, rust-lang#44367, where SIMD-using programs ended up showing very odd
behavior at runtime because the ABI between functions was mismatched.

As a bit of a recap, this is sort of an LLVM bug and sort of an LLVM feature
(today's behavior). LLVM will generate code for a function solely looking at the
function it's generating, including calls to other functions. Let's then say
you've got something that looks like:

```llvm
define void @foo() { ; no target features enabled
  call void @bar(<i64 x 4> zeroinitializer)
  ret void
}

define void @bar(<i64 x 4>) #0 { ; enables the AVX feature
  ...
}
```

LLVM will codegen the call to `bar` *without* using AVX registers becauase `foo`
doesn't have access to these registers. Instead it's generated with emulation
that uses two 128-bit registers. The `bar` function, on the other hand, will
expect its argument in an AVX register (as it has AVX enabled). This means we've
got a codegen problem!

Comments on rust-lang#44367 have some more contexutal information but the crux of the
issue is that if we want SIMD to work in general we'll need to ensure that
whenever a function calls another they ABI of the arguments being passed is in
agreement.

One possible solution to this would be to insert "shim functions" where whenever
a `target_feature` mismatch is detected the compiler inserts a shim function
where you pass arguments via memory to the shim and then the shim loads the
values and calls the target function (where the shim and the target have the
same target features enabled). This unfortunately is quite nontrivial to
implement in rustc today (especially when accounting for function pointers and
such).

This commit takes a different solution, *always* passing SIMD arguments through
memory instead of passing as immediates. This strategy solves the problem at the
LLVM layer because the ABI between two functions never uses SIMD registers. This
also shouldn't be a hit to performance because SIMD performance is thought to
often rely on inlining anyway, where a `call` instruction, even if using SIMD
registers, would be disastrous to performance regardless. LLVM should then be
more than capable of fixing all our memory usage to use registers instead after
enough inlining has been performed.

Note that there's a few caveats to this commit though:

* The "platform intrinsic" ABI is omitted from "always pass via memory". This
  ABI is used to define intrinsics like `simd_shuffle4` where LLVM and rustc
  need to have the arguments as an immediate.

* Additionally this commit does *not* fix the `extern` ("C") ABI. This means
  that the bug in rust-lang#44367 can still happen when using non-Rust-ABI functions. My
  hope is that before stabilization we can ban and/or warn about SIMD types in
  these functions (as AFAIK there's not much motivation to belong there anyway),
  but I'll leave that for a later commit and if this is merged I'll file a
  follow-up issue.

All in all this...

Closes rust-lang#44367

…rister

Teach rustc about DW_AT_noreturn and a few more DIFlags

We achieve two small things with this PR:
1. We provide definitions for a few additional llvm debuginfo flags
1. We _use_ one of these new flags, `FlagNoReturn`, and add it to debuginfo for functions with the never return type (`!`).

rustc_trans: remove an unwrap by replacing a bool with Result.

Prompted by @shepmaster.
r? @nagisa

[perf] Use std based dedup in projection

Unstable sort was added recently, and the code that is being modified is 3 years old. As quicksort doesn't allocate it will likely perform as well as, or better than linear search.

I didn't benchmark. Have a perf run.

do not ICE when return type includes unconstrained anon region

It turns out that this *can* happen after all, if the region is only
used in projections from the input types.

Fixes rust-lang#47511

r? @eddyb

Make use of the implemented red/green algorithm for variance

r? @michaelwoerister

…dreavus

Fixes for intra-doc-links

Turn errors into warnings, also handle methods, trait items, and variants.

r? @killercup @QuietMisdreavus

Fix ICE when use trees have multiple empty nested groups

The issue was caused by an oversight of mine in the original use_nested_groups PR, where different paths were resolved with the same `NodeId` in some cases (such as in `use {{}, {}};`).

Fixes rust-lang#47673
r? @petrochenkov

…atsakis

First round of LLVM 6.0.0 compatibility

This includes a number of commits for the first round of upgrading to LLVM 6. There are still [lingering bugs](rust-lang#47683) but I believe all of this will nonetheless be necessary!

…ns, r=nikomatsakis

Update compiler-builtins submodule

No sense of urgency, just wanted to make sure we don't lag too far behind!

…lexcrichton

Add powerpc to run-pass/conditional-compile-arch.rs

…r/rust into rollup

…into rollup

Accidentally added in e9a6499

Looks like llvm 4.0.0 isn't read for that either.

We can't use git commands to compute a prerelease version when we're
building from a source tarball, or if git is otherwise unavailable.
We'll just call such builds `x.y.z-beta`, without a prerelease.

…r fatal errors

Fixes rust-lang#47364

…llup

…into rollup

…into rollup

… rollup

…o rollup

…nto rollup

…o rollup