interpret: move saturating_add/sub into (pub) helper method
I plan to use them for `simd_saturating_add/sub`.
The first commit just moves code, the 2nd simplifies it a bit with some helper methods that did not exist yet when the code was originally written.
Remove ordering traits from `rustc_span::hygiene::LocalExpnId`
Part of work on #90317.
Also adds a negative impl block as a form of documentation and a roadblock to regression.
Rollup of 4 pull requests
Successful merges:
- #94636 (Check extra function arg exprs even if the fn is not C-variadic)
- #94676 (Remove unnecessary `..` patterns)
- #94681 (CTFE engine: expose misc_cast to Miri)
- #94684 (Fix rustdoc for GATs with with anonymous bound regions)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
CTFE engine: expose misc_cast to Miri
We need that to implement `simd_cast`/`simd_as` in Miri.
While at it, also change other code outside `cast.rs` to use `misc_cast` instead of lower-level methods.
r? `@oli-obk`
Check extra function arg exprs even if the fn is not C-variadic
We should still call check_expr on the args that exceed the formal input ty count, so that we have expr types to emit during writeback.
Not sure where this regressed, but it wasn't due to the same root cause as #94334 I think. I thought this might've regressed in #92360, but I think that is in stable, ad the test I provided (which minimizes #94599) passes on stable in playground. Maybe it regressed in #93118.
Anywho, fixes#94599.
Introduce `ConstAllocation`.
Currently some `Allocation`s are interned, some are not, and it's very
hard to tell at a use point which is which.
This commit introduces `ConstAllocation` for the known-interned ones,
which makes the division much clearer. `ConstAllocation::inner()` is
used to get the underlying `Allocation`.
In some places it's natural to use an `Allocation`, in some it's natural
to use a `ConstAllocation`, and in some places there's no clear choice.
I've tried to make things look as nice as possible, while generally
favouring `ConstAllocation`, which is the type that embodies more
information. This does require quite a few calls to `inner()`.
The commit also tweaks how `PartialOrd` works for `Interned`. The
previous code was too clever by half, building on `T: Ord` to make the
code shorter. That caused problems with deriving `PartialOrd` and `Ord`
for `ConstAllocation`, so I changed it to build on `T: PartialOrd`,
which is slightly more verbose but much more standard and avoided the
problems.
r? `@fee1-dead`
Currently some `Allocation`s are interned, some are not, and it's very
hard to tell at a use point which is which.
This commit introduces `ConstAllocation` for the known-interned ones,
which makes the division much clearer. `ConstAllocation::inner()` is
used to get the underlying `Allocation`.
In some places it's natural to use an `Allocation`, in some it's natural
to use a `ConstAllocation`, and in some places there's no clear choice.
I've tried to make things look as nice as possible, while generally
favouring `ConstAllocation`, which is the type that embodies more
information. This does require quite a few calls to `inner()`.
The commit also tweaks how `PartialOrd` works for `Interned`. The
previous code was too clever by half, building on `T: Ord` to make the
code shorter. That caused problems with deriving `PartialOrd` and `Ord`
for `ConstAllocation`, so I changed it to build on `T: PartialOrd`,
which is slightly more verbose but much more standard and avoided the
problems.
explain why shift with signed offset works the way it does
I was worried for a bit here that Miri/CTFE would be inconsistent with codegen, but I *think* everything is all right, actually.
Cc `@oli-obk` `@eddyb`
Always include global target features in function attributes
This ensures that information about target features configured with
`-C target-feature=...` or detected with `-C target-cpu=native` is
retained for subsequent consumers of LLVM bitcode.
This is crucial for linker plugin LTO, since this information is not
conveyed to the plugin otherwise.
<details><summary>Additional test case demonstrating the issue</summary>
```rust
extern crate core;
#[inline]
#[target_feature(enable = "aes")]
unsafe fn f(a: u128, b: u128) -> u128 {
use core::arch::x86_64::*;
use core::mem::transmute;
transmute(_mm_aesenc_si128(transmute(a), transmute(b)))
}
pub fn g(a: u128, b: u128) -> u128 {
unsafe { f(a, b) }
}
fn main() {
let mut args = std::env::args();
let _ = args.next().unwrap();
let a: u128 = args.next().unwrap().parse().unwrap();
let b: u128 = args.next().unwrap().parse().unwrap();
println!("{}", g(a, b));
}
```
```console
$ rustc --edition=2021 a.rs -Clinker-plugin-lto -Clink-arg=-fuse-ld=lld -Ctarget-feature=+aes -O
...
= note: LLVM ERROR: Cannot select: intrinsic %llvm.x86.aesni.aesenc
```
</details>
r? `@nagisa`
Improve rustdoc const bounds
- Rustdoc no longer displays `~const` in trait bounds, because it currently means nothing for stable users, and because we still haven't decided on the final syntax yet.
- Rustdoc will hide trait bounds where the trait is `Drop` AND it is `~const`, i.e. `~const Drop` bounds because it has no effect on stable users as well.
- Because of additional logic that hides the whole `where` statement where it consists of `~const Drop` bounds (so it doesn't display `struct Foo<T>() where ;` like that), bounds that have no trait e.g. `where [T; N+1]: ;` are also hidden.
Cherry-picked from #92433.
Unix path::absolute: Fix leading "." component
Testing leading `.` and `..` components were missing from the unix tests.
This PR adds them and fixes the leading `.` case. It also fixes the test cases so that they do an exact comparison.
This problem reported by ``@axetroy``
rustbuild: support RelWithDebInfo for lld
r? ``@alexcrichton``
LLVM has flags that control the level of debuginfo generated when building via rustbuild. Since LLD is built separately, it currently has no way of generating any debuginfo. This change re-uses the same flags as LLVM for LLD to ensure it has the same level of debuginfo generated as LLVM.
