Return values up to 128 bits in registers
This fixes https://github.com/rust-lang/rust/issues/26494#issuecomment-619506345 by making Rust's default ABI pass return values up to 128 bits in size in registers, just like the System V ABI.
The result is that these methods from the comment linked above now generate the same code, making the Rust ABI as efficient as the `"C"` ABI:
```rust
pub struct Stats { x: u32, y: u32, z: u32, }
pub extern "C" fn sum_c(a: &Stats, b: &Stats) -> Stats {
return Stats {x: a.x + b.x, y: a.y + b.y, z: a.z + b.z };
}
pub fn sum_rust(a: &Stats, b: &Stats) -> Stats {
return Stats {x: a.x + b.x, y: a.y + b.y, z: a.z + b.z };
}
```
```asm
sum_rust:
movl (%rsi), %eax
addl (%rdi), %eax
movl 4(%rsi), %ecx
addl 4(%rdi), %ecx
movl 8(%rsi), %edx
addl 8(%rdi), %edx
shlq $32, %rcx
orq %rcx, %rax
retq
```
pretty-print-reparse hack: Rename some variables for clarity
This will also make it easier to make the comparisons asymmetric.
Also one impossible case is removed.
r? @Aaron1011
Move helper function for `missing_const_for_fn` out of rustc to clippy
cc @rust-lang/clippy @ecstatic-morse #76618
r? @Manishearth
I also removed all support for suggesting a function could be `const fn` when that would require feature gates to actually work.
This means we'll now have to maintain this ourselves in clippy, but that's how most lints work anyway, so...
Late link args order
MSYS2 changed how winpthreads is built and as the result it now depends on more mingw-w64 libraries.
This PR affects only MinGW targets since nobody else is using `late_link_args_{dynamic,static}`. Now the order is similar to how it used to be before https://github.com/rust-lang/rust/pull/67502.
Enable const propagation into operands at mir_opt_level=2
Feature was added in #74507 but gated with `mir_opt_level>=3` because of compile time regressions. Let's see whether the LLVM 11 update solves that.
As the [perf results](https://github.com/rust-lang/rust/pull/77107#issuecomment-697668154) show, enabling this optimization results in a lot less regression as before.
cc @oli-obk
r? @ghost
Encode less metadata for proc-macro crates
Currently, we serialize the same crate metadata for proc-macro crates as
we do for normal crates. This is quite wasteful - almost none of this
metadata is ever used, and much of it can't even be deserialized (if it
contains a foreign `CrateNum`).
This PR changes metadata encoding to skip encoding the majority of crate
metadata for proc-macro crates. Most of the `Lazy<[T]>` fields are left
completetly empty, while the non-lazy fields are left as-is.
Additionally, proc-macros now have a def span that does not include
their body. This was done for normal functions in #75465, but was missed
for proc-macros.
As a result of this PR, we should only ever encode local `CrateNum`s
when encoding proc-macro crates. I've added a specialized serialization
impl for `CrateNum` to assert this.
Currently, we serialize the same crate metadata for proc-macro crates as
we do for normal crates. This is quite wasteful - almost none of this
metadata is ever used, and much of it can't even be deserialized (if it
contains a foreign `CrateNum`).
This PR changes metadata encoding to skip encoding the majority of crate
metadata for proc-macro crates. Most of the `Lazy<[T]>` fields are left
completetly empty, while the non-lazy fields are left as-is.
Additionally, proc-macros now have a def span that does not include
their body. This was done for normal functions in #75465, but was missed
for proc-macros.
As a result of this PR, we should only ever encode local `CrateNum`s
when encoding proc-macro crates. I've added a specialized serialization
impl for `CrateNum` to assert this.
Remove TrustedLen requirement from BuilderMethods::switch
The main use case of TrustedLen is allowing APIs to specialize on it,
but no use of it uses that specialization. Instead, only the .len()
function provided by ExactSizeIterator is used, which is already
required to be accurate.
Thus, the TrustedLen requirement on BuilderMethods::switch is redundant.
Add `#![feature(const_fn_floating_point_arithmetic)]`
cc #76618
This is a template for splitting up `const_fn` into granular feature gates. I think this will make it easier, both for us and for users, to track stabilization of each individual feature. We don't *have* to do this, however. We could also keep stabilizing things out from under `const_fn`.
cc @rust-lang/wg-const-eval
r? @oli-obk
Rollup of 15 pull requests
Successful merges:
- #76932 (Relax promises about condition variable.)
- #76973 (Unstably allow assume intrinsic in const contexts)
- #77005 (BtreeMap: refactoring around edges)
- #77066 (Fix dest prop miscompilation around references)
- #77073 (dead_code: look at trait impls even if they don't contain items)
- #77086 (Include libunwind in the rust-src component.)
- #77097 (Make [].as_[mut_]ptr_range() (unstably) const.)
- #77106 (clarify that `changelog-seen = 1` goes to the beginning of config.toml)
- #77120 (Add `--keep-stage-std` to `x.py` for keeping only standard library artifacts)
- #77126 (Invalidate local LLVM cache less often)
- #77146 (Install std for non-host targets)
- #77155 (remove enum name from ImplSource variants)
- #77176 (Removing erroneous semicolon in transmute documentation)
- #77183 (Allow multiple allow_internal_unstable attributes)
- #77189 (Remove extra space from vec drawing)
Failed merges:
r? `@ghost`
This refactors handling of `Rvalue::{Unary,Binary}Op` in the
const-checker. Now we `span_bug` if there's an unexpected type in a
primitive operation. This also allows unary negation on
`char` values through the const-checker because it makes the code a bit
cleaner. `char` does not actually support these operations, and if it
did, we could evaluate them at compile-time.
Ignore ZST offsets when deciding whether to use Scalar/ScalarPair layout
This is important because Scalar/ScalarPair layout previously would not be used if any ZST had nonzero offset.
For example, before this change, only `((), u128)` would be laid out like `u128`, not `(u128, ())`.
Fixes#63244
perf: move cold path of `process_obligations` into a separate function
cc #76575
This probably won't matter too much in the long run once #69218 is merged so we may not want to merge this.
r? `@ecstatic-morse`
