small interpreter error cleanup
- Add `InterpretResult::map_err_kind` for the common case of swapping out the error kind (while preserving the backtrace pointing to the original error source)
- Rename `InterpError` -> `InterpErrorKind` to be consistent with the `kind` field name, and make it more clear that this is not the final error type
Return values larger than 2 registers using a return area pointer
LLVM and Cranelift disagree about how to return values that don't fit in the registers designated for return values. LLVM will force the entire return value to be passed by return area pointer, while Cranelift will look at each IR level return value independently and decide to pass it in a register or not, which would result in the return value being passed partially in registers and partially through a return area pointer.
While Cranelift may need to be fixed as the LLVM behavior is generally more correct with respect to the surface language, forcing this behavior in rustc itself makes it easier for other backends to conform to the Rust ABI and for the C ABI rustc already handles this behavior anyway.
In addition LLVM's decision to pass the return value in registers or using a return area pointer depends on how exactly the return type is lowered to an LLVM IR type. For example `Option<u128>` can be lowered as `{ i128, i128 }` in which case the x86_64 backend would use a return area pointer, or it could be passed as `{ i32, i128 }` in which case the x86_64 backend would pass it in registers by taking advantage of an LLVM ABI extension that allows using 3 registers for the x86_64 sysv call conv rather than the officially specified 2 registers.
This adjustment is only necessary for the Rust ABI as for other ABI's the calling convention implementations in rustc_target already ensure any return value which doesn't fit in the available amount of return registers is passed in the right way for the current target.
Helps with https://github.com/rust-lang/rustc_codegen_cranelift/issues/1525
cc https://github.com/bytecodealliance/wasmtime/issues/9250
Never emit `vptr` for empty/auto traits
Emiting `vptr`s for empty/auto traits is unnecessary (#114942) and causes unsoundness in `trait_upcasting` (#131813). This PR should ensure that we never emit vtables for such traits. See the linked issues for more details.
I'm not sure if I can add tests for the vtable layout. So this PR only adds tests for the soundness hole (i.e., the segmentation fault will disappear after this PR).
Fixes#114942Fixes#131813
Cc #65991 (tracking issue for `trait_upcasting`)
r? `@WaffleLapkin` (per https://github.com/rust-lang/rust/issues/131813#issuecomment-2419969745)
Default to the medium code model on OpenHarmony LoongArch target
The context for this is #130266: setting the medium code model for the `loongarch64-linux-ohos` target.
r? ```@jieyouxu```
Dont ICE when computing coverage of synthetic async closure body
I'm not totally certain if this is *right*, but at least it doesn't ICE.
The issue is that we end up generating two MIR bodies for each async closure, since the `FnOnce` and `Fn`/`FnMut` implementations have different borrowing behavior of their captured variables. They should ideally both contribute to the coverage, since those MIR bodies are (*to the user*) the same code and should have no behavioral differences.
This PR at least suppresses the ICEs, and then I guess worst case we can fix this the right way later.
r? Zalathar or re-roll
Fixes#131190
Allow dropping dyn principal
Revival of #126660, which was a revival of #114679. Fixes#126313.
Allows dropping principal when coercing trait objects, e.g. `dyn Debug + Send` -> `dyn Send`.
cc `@compiler-errors` `@Jules-Bertholet`
r? `@lcnr`
compiler: use `is_none_or` where it is clearly better
heuristic was: if it easily allows removing bangs entirely? worth it. if it requires more effort or just moves the bang? not.
cleanup canonical queries
best reviewed commit by commit. adding `CanonicalQueryInput` to stop returning `defining_opaque_types` in query responses is the most involved change here.
r? ``@compiler-errors``
Setting up indirect access to external data for loongarch64-linux-{musl,ohos}
In issue #118053, the `loongarch64-unknown-linux-gnu` target needs indirection to access external data, and so do the `loongarch64-unknown-linux-musl` and `loongarch64-unknown-linux-ohos` targets.
Make destructors on `extern "C"` frames to be executed
This would make the example in #123231 print "Noisy Drop". I didn't mark this as fixing the issue because the behaviour is yet to be spec'ed.
Tracking:
- https://github.com/rust-lang/rust/issues/74990
Fix needless_lifetimes in stable_mir
Hi,
This PR fixes the following clippy warning
```
warning: the following explicit lifetimes could be elided: 'a
--> compiler/stable_mir/src/mir/visit.rs:490:6
|
490 | impl<'a> PlaceRef<'a> {
| ^^ ^^
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#needless_lifetimes
= note: `#[warn(clippy::needless_lifetimes)]` on by default
help: elide the lifetimes
|
490 - impl<'a> PlaceRef<'a> {
490 + impl PlaceRef<'_> {
|
```
Best regards,
Michal
Fix trivially_copy_pass_by_ref in stable_mir
Hi,
This PR fixes the following clippy warnings
```
warning: this argument (8 byte) is passed by reference, but would be more efficient if passed by value (limit: 8 byte)
--> compiler/stable_mir/src/mir/body.rs:1042:34
|
1042 | fn subslice_ty(ty: Ty, from: &u64, to: &u64, from_end: &bool) -> Result<Ty, Error> {
| ^^^^ help: consider passing by value instead: `u64`
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#trivially_copy_pass_by_ref
= note: requested on the command line with `-W clippy::trivially-copy-pass-by-ref`
warning: this argument (8 byte) is passed by reference, but would be more efficient if passed by value (limit: 8 byte)
--> compiler/stable_mir/src/mir/body.rs:1042:44
|
1042 | fn subslice_ty(ty: Ty, from: &u64, to: &u64, from_end: &bool) -> Result<Ty, Error> {
| ^^^^ help: consider passing by value instead: `u64`
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#trivially_copy_pass_by_ref
warning: this argument (1 byte) is passed by reference, but would be more efficient if passed by value (limit: 8 byte)
--> compiler/stable_mir/src/mir/body.rs:1042:60
|
1042 | fn subslice_ty(ty: Ty, from: &u64, to: &u64, from_end: &bool) -> Result<Ty, Error> {
| ^^^^^ help: consider passing by value instead: `bool`
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#trivially_copy_pass_by_ref
```
Best regards,
Michal
Rename `can_coerce` to `may_coerce`, and then structurally resolve correctly in the probe
We need to structurally resolve the lhs and rhs of the coercion. Also, renaming the method so it's less ambiguous about what it's doing... the word "may" gives more clear signal that it has false positives imo.
r? lcnr
Don't check unsize goal in MIR validation when opaques remain
Similarly to `mir_assign_valid_types`, let's just skip when there are opaques. Fixes#130921.
Fix explicit_iter_loop in rustc_serialize
Hi,
This PR fixes some clippy warnings
```
warning: it is more concise to loop over references to containers instead of using explicit iteration methods
--> compiler/rustc_serialize/src/serialize.rs:675:18
|
675 | for e in self.iter() {
| ^^^^^^^^^^^ help: to write this more concisely, try: `self`
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#explicit_iter_loop
```
Best regards,
Michal
Try to improve error messages involving aliases in the solver
1. Treat aliases as rigid only if it may not be defined and it's well formed (i.e. for projections, its trait goal is satisfied).
2. Record goals that are related to alias normalization under a new `GoalKind`, so we can look into them in the `BestObligation` visitor.
3. Try to deduplicate errors due to self types of goals that are un-normalizable aliases.
r? lcnr
Add fast-path when computing the default visibility
This PR adds (or more correctly re-adds the) fast-path when computing the default visibility, by taking advantage of the fact that the "interposable" requested visibility always return the "default" codegen visibility.
Should address the small regression observed in https://github.com/rust-lang/rust/pull/131111#issuecomment-2402273967.
r? `@lqd`
