Update to LLVM 9 trunk
Following the preparatory changes in #62474, this updates the LLVM submodule to https://github.com/rust-lang/llvm-project/tree/rustc/9.0-2019-07-12 and:
* Changes the LLVM Rust bindings to account for the new SubtargetSubTypeKV.
* Adjusts a codegen test for the new form of the byval attribute that takes a type.
* Makes a PGO codegen test more liberal with regard to order and linkage.
* Builds InstrProfilingPlatformWindows.c as part of libprofiler_builtins.
* Moves registration of additional passes (in particular sanitizers) to the end of the module pass manager.
* Disables LLDB on builders.
r? @alexcrichton
Don't require a specific order for the per-function globals, and
don't require the locals to have private linkage (apparently
internal linkage is also possible).
Refactor C FFI variadics to more closely match their C counterparts, and add Clone implementation
We had to make some changes to expose `va_copy` and `va_end` directly to users (mainly for C2Rust, but not exclusively):
- redefine the Rust variadic structures to more closely correspond to C: `VaList` now matches `va_list`, and `VaListImpl` matches `__va_list_tag`
- add `Clone` for `VaListImpl`
- add explicit `as_va_list()` conversion function from `VaListImpl` to `VaList`
- add deref coercion from `VaList` to `VaListImpl`
- add support for the `asmjs` target
All these changes were needed for use cases like:
```Rust
let mut ap2 = va_copy(ap);
vprintf(fmt, ap2);
va_end(&mut ap2);
```
Help LLVM better optimize slice::Iter(Mut)::len
r? @RalfJung
I've included a codegen test that fails without this change as a demonstration of usefulness.
move some tests into subfolders
This reduces the size of the test folders without making the moved tests harder to find.
Is this kind of change desired/worth the effort?
Stabilize #![feature(repr_align_enum)] in Rust 1.37.0
On an `enum` item, you may now write:
```rust
#[repr(align(X))]
enum Foo {
// ...
}
```
This has equivalent effects to first defining:
```rust
#[repr(align(X))]
struct AlignX<T>(T);
```
and then using `AlignX<Foo>` in `Foo`'s stead.
r? @nagisa
Added ignore-sgx for appropriate tests in src/test
These are all the tests that make sense to ignore when targeting fortanix-unknonw-sgx, at least in test/runpass. Other suites not yet covered.
Remove bitrig support from rust
Resolves#60743
using `find` and `rg` I delete every occurence of "bitrig" in the sources, expect for the llvm submodule (is this correct?).
There's also this file 5b8e99bb61/rls-analysis/test_data/rust-analysis/libstd-af9bacceee784405.json which contains a bitrig string in it. What to do with that?
Over in #60378, we made `rustc` switch LLVM target triples dynamically
based on the `MACOSX_DEPLOYMENT_TARGET` environment variable. This
change was made to align with `clang`'s behavior, and therefore make
cross-language LTO feasible on OS X. Otherwise, `rustc` would produce
LLVM bitcode files with a target triple of `x86_64-apple-darwin`,
`clang` would produce LLVM bitcode files with a target triple of
`x86_64-apple-macosx$VERSION`, and the linker would complain.
This change worked fine, except for one corner case: if you didn't have
`MACOSX_DEPLOYMENT_TARGET` set, and you wanted to do LTO on just Rust
code, you'd get warning messages similar to:
```
warning: Linking two modules of different target triples: ' is 'x86_64-apple-macosx10.7.0' whereas 'main.7rcbfp3g-cgu.4' is 'x86_64-apple-darwin'
```
This message occurs because libstd is compiled with
`MACOSX_DEPLOYMENT_TARGET` set to 10.7. The LLVM bitcode distributed in
libstd's rlibs, then, is tagged with the target triple of
`x86_64-apple-macosx10.7.0`, while the bitcode `rustc` produces for
"user" code is tagged with the target triple of `x86_64-apple-darwin`.
It's not good to have LTO on just Rust code (probably much more common
than cross-language LTO) warn by default. These warnings also break
Cargo's testsuite.
This change defaults to acting as though `MACOSX_DEPLOYMENT_TARGET` was
set to 10.7. "user" code will then be given a target triple that is
equivalent to the target triple libstd bitcode is already using. The
above warning will therefore go away.
`rustc` already assumes that compiling without
`MACOSX_DEPLOYMENT_TARGET` means that we're compiling for a target
compatible with OS X 10.7 (e.g. that things like TLS work properly). So
this change is really just making things conform more closely to the
status quo.
(It's also worth noting that before and after this patch, compiling with
`MACOSX_DEPLOYMENT_TARGET` set to, say, 10.9, works just fine: target
triples with an "apple" version ignore OS versions when checking
compatibility, so bitcode with a `x86_64-apple-macosx10.7.0` triple works just
fine with bitcode with a `x86_64-apple-macosx10.9.0` triple.)
Add codegen test for PGO instrumentation.
This PR adds a codegen test that makes sure that LLVM actually generates instrumentation code when we enable PGO instrumentation in `rustc`.
The second commit updates a test case to the new commandline option syntax introduced in #59874. Without the fix the test still works, but it confusingly creates a directory called `test.profraw`, which usually is the name of the _file_ where profiling data is collected.
Never return uninhabited values at all
Functions with uninhabited return values are already marked `noreturn`,
but we were still generating return instructions for this. When running
with `-C passes=lint`, LLVM prints:
Unusual: Return statement in function with noreturn attribute
The LLVM manual makes a stronger statement about `noreturn` though:
> This produces undefined behavior at runtime if the function ever does
dynamically return.
We now emit an `abort` anywhere that would have tried to return an
uninhabited value.
Fixes#48227
cc #7463#48229
r? @eddyb
Functions with uninhabited return values are already marked `noreturn`,
but we were still generating return instructions for this. When running
with `-C passes=lint`, LLVM prints:
Unusual: Return statement in function with noreturn attribute
The LLVM manual makes a stronger statement about `noreturn` though:
> This produces undefined behavior at runtime if the function ever does
dynamically return.
We now emit an `abort` anywhere that would have tried to return an
uninhabited value.
Fix stack overflow when generating debuginfo for 'recursive' type
By using 'impl trait', it's possible to create a self-referential
type as follows:
fn foo() -> impl Copy { foo }
This is a function which returns itself.
Normally, the signature of this function would be impossible
to write - it would look like 'fn foo() -> fn() -> fn() ...'
e.g. a function which returns a function, which returns a function...
Using 'impl trait' allows us to avoid writing this infinitely long
type. While it's useless for practical purposes, it does compile and run
However, issues arise when we try to generate llvm debuginfo for such a
type. All 'impl trait' types (e.g. ty::Opaque) are resolved when we
generate debuginfo, which can lead to us recursing back to the original
'fn' type when we try to process its return type.
To resolve this, I've modified debuginfo generation to account for these
kinds of weird types. Unfortunately, there's no 'correct' debuginfo that
we can generate - 'impl trait' does not exist in debuginfo, and this
kind of recursive type is impossible to directly represent.
To ensure that we emit *something*, this commit emits dummy
debuginfo/type names whenever it encounters a self-reference. In
practice, this should never happen - it's just to ensure that we can
emit some kind of debuginfo, even if it's not particularly meaningful
Fixes#58463
Fix LLVM IR generated for C-variadic arguments
It is possible to create malformed LLVM IR given variadic arguments that
are aggregate types. This occurs due to improper tracking of the current
argument in the functions list of arguments.
Fixes: #58881
It is possible to create malformed LLVM IR given variadic arguments that
are aggregate types. This occurs due to improper tracking of the current
argument in the functions list of arguments.
