| Age | Commit message (Collapse) | Author | Lines |
|---|
|
future
Also expand the documentation a bit
|
|
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.
|
|
Use -Zborrowck=mir for NLL compare mode
closes #56993
r? @pnkfelix
|
|
|
|
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 https://github.com/rust-lang/rls/blob/5b8e99bb61958ca8abcb7c5eda70521726be1065/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.)
|
|
|
|
|
|
This behavior matches clang's behavior, and makes cross-language LTO
possible.
Fixes #60235.
|
|
|
|
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.
|
|
|
|
|
|
|
|
Since commit 9452a8dfa3ba, the new debug info format is only generated
for LLVM 8 and newer versions. However, the tests still assume that LLVM
7 will use the new debug info format. Fix the tests (and a comment in
the code) to match the actual version check.
|
|
`va_start` and `va_end` must be called to initialize/cleanup the
"spoofed" `VaList` in a Rust defined C-variadic function even if
the `VaList` is not used.
|
|
Add support for defining C compatible variadic functions in unsafe rust
with extern "C".
|
|
Use normal mutable borrows in matches
`ref mut` borrows are currently two-phase with NLL enabled. This changes them to be proper mutable borrows. To accommodate this, first the position of fake borrows is changed:
```text
[ 1. Pre-match ]
|
[ (old create fake borrows) ]
[ 2. Discriminant testing -- check discriminants ] <-+
| |
| (once a specific arm is chosen) |
| |
[ (old read fake borrows) ] |
[ 3. Create "guard bindings" for arm ] |
[ (create fake borrows) ] |
| |
[ 4. Execute guard code ] |
[ (read fake borrows) ] --(guard is false)-----------+
|
| (guard results in true)
|
[ 5. Create real bindings and execute arm ]
|
[ Exit match ]
```
The following additional changes are made to accommodate `ref mut` bindings:
* We no longer create fake `Shared` borrows. These borrows are no longer needed for soundness, just to avoid some arguably strange cases.
* `Shallow` borrows no longer conflict with existing borrows, avoiding conflicting access between the guard borrow access and the `ref mut` borrow.
There is some further clean up done in this PR:
* Avoid the "later used here" note for Shallow borrows (since it's not relevant with the message provided)
* Make any use of a two-phase borrow activate it.
* Simplify the cleanup_post_borrowck passes into a single pass.
cc #56254
r? @nikomatsakis
|
|
Implement unstable ffi_return_twice attribute
This PR implements [RFC2633](https://github.com/rust-lang/rfcs/pull/2633)
r? @eddyb
|
|
Add generic simd saturated add/sub intrinsics
r? @eddyb
|
|
|
|
|
|
|
|
|
|
|
|
MaybeUninit: some docs, rename into_inner -> into_initialized, return &mut from set
|
|
|
|
|
|
|
|
|
|
Implement optimize(size) and optimize(speed) attributes
This PR implements both `optimize(size)` and `optimize(speed)` attributes.
While the functionality itself works fine now, this PR is not yet complete: the code might be messy in places and, most importantly, the compiletest must be improved with functionality to run tests with custom optimization levels. Otherwise the new attribute cannot be tested properly. Oh, and not all of the RFC is implemented – attribute propagation is not implemented for example.
# TODO
* [x] Improve compiletest so that tests can be written;
* [x] Assign a proper error number (E9999 currently, no idea how to allocate a number properly);
* [ ] Perhaps reduce the duplication in LLVM attribute assignment code…
|
|
The new git submodule src/llvm-project is a monorepo replacing src/llvm
and src/tools/{clang,lld,lldb}. This also serves as a rebase for these
projects to the new 8.x branch from trunk.
The src/llvm-emscripten fork is unchanged for now.
|
|
`compile-flags: -Copt-level` will avoid adding -O. Similarly for -g and
-Cdebuglevel.
|
|
Alas it does not currently work, because of limitations in compiletest…
|
|
|
|
|
|
Enable emission of alignment attrs for pointer params
Instead disable creation of assumptions during inlining using an LLVM opt flag. For non-inlined functions, this gives us alignment information, while not inserting any assumes that kill other optimizations.
The `-Z arg-align-attributes` option which previously controlled this behavior is removed.
Fixes #54982.
r? @nagisa
cc @eddyb who added the current behavior, and @scottmcm, who added the `-Z arg-align-attributes` flag.
|
|
Ignore two tests on s390x
Ignore two tests on s390x which don't make sense on s390x as they are x86-specific.
|
|
Fix alignment for array indexing
We need to reduce the alignment with the used offset. If the offset isn't known, use the element size, as this will yield the minimum possible alignment.
This handles both direct array indexing, and array repeat expressions.
Fixes #56927.
r? @nagisa
|
|
|
|
We need to reduce the alignment with the used offset. If the offset
isn't known, we need to reduce with the element size to support
arbitrary offsets.
|
