explicit tail calls: support indirect arguments
tracking issue: https://github.com/rust-lang/rust/issues/112788
After discussion in https://github.com/rust-lang/rust/issues/144855, I was wrong and it is actually possible to support tail calls with `PassMode::Indirect { on_stack: false, .. }` arguments.
Normally an indirect argument with `on_stack: false` would be passed as a pointer into the caller's stack frame. For tail calls, that would be unsound, because the caller's stack frame is overwritten by the callee's stack frame.
Therefore we store the argument for the callee in the corresponding caller's slot. Because guaranteed tail calls demand that the caller's signature matches the callee's, the corresponding slot has the correct type.
To handle cases like the one below, the tail call arguments must first be copied to a temporary, and can only then be copied to the caller's argument slots.
```rust
// A struct big enough that it is not passed via registers.
pub struct Big([u64; 4]);
fn swapper(a: Big, b: Big) -> (Big, Big) {
become swapper_helper(b, a);
}
```
---
I'm not really familiar with MIR and what tricks/helpers we have, so I'm just cobbling this together. Hopefully we can arrive at something more elegant.
Avoid duplicate `requirement` diag args in `RegionOriginNote`
Fixesrust-lang/rust#143872
`RegionOriginNote::WithRequirement` can be emitted multiple times for one
diagnostic. I fixed the ICE by scoping per note fluent args in `RegionOriginNote::WithRequirement` with `store_args` and `restore_args`.
Rename `rustc::pass_by_value` lint as `rustc::disallowed_pass_by_ref`.
The name `pass_by_value` is completely wrong. The lint actually checks for the use of pass by reference for types marked with `rustc_pass_by_value`.
The hardest part of this was choosing the new name. The `disallowed_` part of the name closely matches the following clippy lints:
- `disallowed_macros`
- `disallowed_methods`
- `disallowed_names`
- `disallowed_script_idents`
- `disallowed_types`
The `pass_by_value` part of the name aligns with the following clippy lints:
- `needless_pass_by_value`
- `needless_pass_by_ref_mut`
- `trivially_copy_pass_by_ref`
- `large_types_passed_by_value` (less so)
r? @Urgau
deprecate `Eq::assert_receiver_is_total_eq` and emit FCW on manual impls
The `Eq::assert_receiver_is_total_eq` method is purely meant as an implementation detail by `#[derive(Eq)]` to add checks that all fields of the type the derive is applied to also implement `Eq`.
The method is already `#[doc(hidden)]` and has a comment saying `// This should never be implemented by hand.`.
Unfortunately, it has been stable since 1.0 and there are some cases on GitHub (https://github.com/search?q=assert_receiver_is_total_eq&type=code) where people have implemented this method manually, sometimes even with actual code in the method body (example: https://github.com/Shresht7/codecrafters-redis-rust/blob/31f0ec453c504b4ab053a7b1c3ff548ff36a9db5/src/parser/resp/types.rs#L255).
To prevent further confusion from this, this PR is deprecating the method and adds a FCW when it is manually implemented (this is necessary as the deprecation warning is not emitted when the method is implemented, only when it is called).
This is similar to what was previously done with the `soft_unstable` lint (https://github.com/rust-lang/rust/issues/64266).
See also https://github.com/rust-lang/libs-team/issues/704.
The name `pass_by_value` is completely wrong. The lint actually checks
for the use of pass by reference for types marked with
`rustc_pass_by_value`.
The hardest part of this was choosing the new name. The `disallowed_`
part of the name closely matches the following clippy lints:
- `disallowed_macros`
- `disallowed_methods`
- `disallowed_names`
- `disallowed_script_idents`
- `disallowed_types`
The `pass_by_value` part of the name aligns with the following clippy
lints:
- `needless_pass_by_value`
- `needless_pass_by_ref_mut`
- `trivially_copy_pass_by_ref`
- `large_types_passed_by_value` (less so)
Fix attribute parser and kind names.
For the attribute `FooBar` the parser is generally called `FooBarParser` and the kind is called `AttributeKind::FooBar`. This commit renames some cases that don't match that pattern. The most common cases:
- Adding `Rustc` to the front of the parser name for a `rustc_*` attribute.
- Adding `Parser` to the end of a parser name.
- Slight word variations, e.g. `Deprecation` instead of `Deprecated`, `Pointer` instead of `Ptr`, `Stability` instead of `Stable`.
r? @JonathanBrouwer
delete some very old trivial `Box` tests
There's still lots more of these tests; these are just a few duplicated ones I found. None of the tests really test for something interesting except that `Deref{Mut}` trivially works with boxes, but there are still loads of more tests that do the same.
In the past, these tests presumably looked more different to each other than today, with `Box`-like pointers being primitives etc.
This PR is also to check whether such changes (deleting of useless tests) are wanted in general.
Part of rust-lang/rust#133895.
Implement debuginfo for unsafe binder types
Fixes: rust-lang/rust#139462
This treats an unsafe binder like a struct with a single field. This way we'd have the binder's distinct type name while keeping the wrapped value accessible.
Tracking:
- https://github.com/rust-lang/rust/issues/130516
For the attribute `FooBar` the parser is generally called `FooBarParser`
and the kind is called `AttributeKind::FooBar`. This commit renames some
cases that don't match that pattern. The most common cases:
- Adding `Rustc` to the front of the parser name for a `rustc_*`
attribute.
- Adding `Parser` to the end of a parser name.
- Slight word variations, e.g. `Deprecation` instead of `Deprecated`,
`Pointer` instead of `Ptr`, `Stability` instead of `Stable`.
fix error on missing value for -C flags
Before:
```
error: codegen option `panic` requires either `unwind`, `abort`, or `immediate-abort` (C panic=<value>)
```
After:
```
error: codegen option `panic` requires either `unwind`, `abort`, or `immediate-abort` (`-C panic=<value>`)
```
The second commit renames a field in the options macro for better consistency; that did not seem worth its own PR.
mGCA: Enforce WF element types for array valtrees
Fixesrust-lang/rust#152125
Extends WellFormedness checking for const generics to validate that array element types in ValTrees match the declared element type.
### Problem
Before commit, this would have incorrectly compiled
``` rust
#![feature(adt_const_params, min_generic_const_args)]
use std::marker::ConstParamTy;
#[derive(Eq, PartialEq, ConstParamTy)]
struct Foo;
struct Bar;
fn foo<const N: [Foo; 1]>() {}
fn main() {
foo::<{ [Bar] }>();
}
```
### Solution
Added a `ty::Array` arm to checking WellFormedness (similar to the existing `ty::Tuple` arm from rust-lang/rust#150713) which creates `ConstArgHasType` obligations for each array element, ensuring they match the array's declared element type.
I attempted to combine the `Tuple` and `Array` arms into a single arm, but this proved difficult due to pattern matching limitations, and the separate arm is more readable anyway.
### Tests
Added UI test which verifies that the type mismatch is now properly caught, and also returns an appropriate test message
r? @BoxyUwU
Rémy Rakic