Work around a false `err.emit();` type error in rust-analyzer
For whatever reason, rust-analyzer doesn't see that these calls to `err.emit();` are diverging, so the trailing semicolon makes r-a complain about a type mismatch between `()` and some other type.
Removing the trailing semicolon makes no functional difference (because the emit still unwinds the stack), but seems to be enough to allow rust-analyzer to see that emitting an error returns `!` in these cases, which silences the false error.
rustc_public: remove the `CrateDefItems` trait
This trait feels sus since its documentation says it's for 'retrieving all items from a definition' however it only provides an `associated_items` method (??), which I believe should only be valid for `impl`s and `trait`s.
Clarify a confusing green-path function
The current name of this function, `try_load_from_disk_and_cache_in_memory`, is confusing on a number of levels:
- Trying to mark the node green is load-bearing even for queries that never cache to disk.
- It will only return None if it fails to mark the query green; the subsequent parts always return Some.
- If it cannot load a value from disk, it will obtain a value by invoking the query provider.
- It is not actually responsible for storing values in the in-memory cache; that is handled by an outer layer.
This PR therefore:
- Hoists the try-mark-green out of that function, making the function always return a value.
- Renames the function to `load_from_disk_or_invoke_provider_green `.
- Renames a few other local variables in passing.
There should be no change to compiler behaviour.
Stop using `LinkedGraph` in `lexical_region_resolve`
There are only two users of the older `LinkedGraph` data structure, and this is one.
It turns out that this diagnostic-related code doesn't need any non-trivial graph operations (since it does its own graph traversal); it just needs the ability to get a list of in-edges or out-edges (constraints) for any particular node. That's easy enough to do with a simple custom data structure.
Inspired by https://github.com/rust-lang/rust/pull/152621, which wants to make changes to `LinkedGraph` that wouldn't make sense for this use-site.
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.
Clean up some code related to `QueryVTable::execute_query_fn`
This PR is an assortment of small cleanups to code that interacts with `execute_query_fn` in the query vtable.
I also experimented with trying to replace the macro-generated `__rust_end_short_backtrace` functions with a single shared generic function, but I couldn't manage to avoid breaking short backtraces, so I left a note behind to document my attempt.
r? nnethercote (or compiler)
Port `#[rustc_autodiff]` to the attribute parser infrastructure
For https://github.com/rust-lang/rust/issues/131229
r? @jdonszelmann
cc @ZuseZ4
`autodiff_forward` and `autodiff_reverse` can be ported in a seperate PR, but these are expanded in the AST and don't exist anymore in the HIR so this is a bit more of a challenge.
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`.
It's currently in `dep_node.rs`, along with a blanket impl. Specific
impls are in `dep_node_key.rs`. This commit moves the trait and the
blanket impl into `dep_node_key.rs`, so everything is in one place.
This function is tricky to document, and there's more that could be said here,
but I don't want to take up too much vertical space, or add too much risk of
details becoming inaccurate over time.
All three of these functions were previously taking `cache` and
`execute_query_fn` as separate arguments, but after some other recent
simplifications we can just pass `&'tcx QueryVTable<'tcx, C>` instead.
This makes it easier to see where `execute_query_fn` is actually called.
`is_ty_must_use`: do not require a `span` argument
All callers of `is_ty_must_use()`, recursive or not, pass `span` as equal to `expr.span` alongside `expr`. The `span` parameter can be safely removed.
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.
rustc_target: callconv: powerpc64: Use llvm_abiname rather than target_abi for ABI determination
Currently on PowerPC64 targets, `llvm_abiname` and `target_abi` will be the same unless we're on AIX. Since `llvm_abiname` is what we pass on to LLVM, it is preferable to use the value of that to determine the calling convention rather than `target_abi`.
All PowerPC64 targets set both `llvm_abiname` and `target_abi` to the respective ELF ABIs, with the exception of AIX. This is a non-functional change.
Noticed this in the follow-up discussion from rust-lang/rust#150468 and also requested by @RalfJung [here](https://github.com/rust-lang/rust/pull/150468#discussion_r2842291237).
r? @RalfJung
Shoyu Vanilla