Fix `dropping_copy_types` lint from linting in match-arm with side-effects
This PR fixes an issue with the `dropping_copy_types` and `dropping_references` lints when not all patterns that can have side-effects were detected and ignored.
Nearly _fixes_ https://github.com/rust-lang/rust/issues/112653 (will need beta-backport to completely fix the issue)
r? ``@Nilstrieb``
Make simd_shuffle_indices use valtrees
This removes the second-to-last user of the `destructure_mir_constant` query. So in a follow-up we can remove the query and just move the query provider function directly into pretty printing (which is the last user).
cc `@rust-lang/clippy` there's a small functional change, but I think it is correct?
Implement most of MCP510
This implements most of what remains to be done for MCP510:
- turns `-C link-self-contained` into a `+`/`-` list of components, like `-C link-self-contained=+linker,+crto,+libc,+unwind,+sanitizers,+mingw`. The scaffolding is present for all these expected components to be implemented and stabilized in the future on their own time. This PR only handles the `-Zgcc-ld=lld` subset of these link-self-contained components as `-Clink-self-contained=+linker`
- handles `-C link-self-contained=y|n` as-is today, for compatibility with `rustc_codegen_ssa:🔙🔗:self_contained`'s [explicit opt-in and opt-out](9eee230cd0/compiler/rustc_codegen_ssa/src/back/link.rs (L1671-L1676)).
- therefore supports our plan to opt out of `rust-lld` (when it's enabled by default) even for current `-Clink-self-contained` users, with e.g. `-Clink-self-contained -Clink-self-contained=-linker`
- turns `add_gcc_ld_path` into its expected final form, by using the `-C link-self-contained=+linker` CLI flag, and whether the `LinkerFlavor` has the expected `Cc::Yes` and `Lld::Yes` shape (this is not yet the case in practice for any CLI linker flavor)
- makes the [new clean linker flavors](https://github.com/rust-lang/rust/pull/96827#issuecomment-1208441595) selectable in the CLI in addition to the legacy ones, in order to opt-in to using `cc` and `lld` to emulate `-Zgcc-ld=lld`
- ensure the new `-C link-self-contained` components, and `-C linker-flavor`s are unstable, and require `-Z unstable-options` to be used
The up-to-date set of flags for the future stable CLI version of `-Zgcc-ld=lld` is currently: `-Clink-self-contained=+linker -Clinker-flavor=gnu-lld-cc -Zunstable-options`.
It's possible we'll also need to do something for distros that don't ship `rust-lld`, but maybe there are already no tool search paths to be added to `cc` in this situation anyways.
r? `@petrochenkov`
Rollup of 6 pull requests
Successful merges:
- #113168 (fix(resolve): skip assertion judgment when NonModule is dummy)
- #113174 (Better messages for next on a iterator inside for loops)
- #113182 (Error when RPITITs' hidden types capture more lifetimes than their trait definitions)
- #113196 (Fix associated items effective visibility calculation for type privacy lints)
- #113226 (Fix try builds on the msvc builder)
- #113227 (Update cargo)
r? `@ghost`
`@rustbot` modify labels: rollup
Error when RPITITs' hidden types capture more lifetimes than their trait definitions
This implements a stricter set of captures rules for RPITITs. They now may only capture:
1. Lifetimes from the impl header (both the self type and any trait substs -- we may want to restrict just to the self type's lifetimes, but the PR makes that easy to do, too)
2. Lifetimes mentioned by the `impl Trait` in the trait method's definition.
Namely, they may not mention lifetimes from the method (early or late) that are not mentioned in the `impl Trait`.
cc #105258 which I think was trying to do this too, though I'm not super familiar with what exactly differs from that or why that one was broken.
cc #112194 (doesn't fix this issue per se, because it's still an open question, but I think this is objectively better than the status quo, and gets us closer to resolving that issue.)
Technically is a fix for the ICE in #108580, but it turns that issue into an error now. We can decide separately whether or not nested RPITITs should capture lifetimes from their parents.
r? ``@oli-obk``
fix(resolve): skip assertion judgment when NonModule is dummy
Fixes#85992
## Why #85992 panic
During `resolve_imports`, the `path_res` of the import `issue_85992_extern_2::Outcome` is pointing to `external::issue_85992_extern_2` instead of `crate::issue_85992_extern_2`. As a result `import.imported_module.set` had been executed.
Attached 1: the state of `early_resolve_ident_in_lexical_scope` during the `resolve_imports` for `use issue_85992_extern_2::Outcome` is as follows:
|iter in `visit_scopes` | `scope` | `result.binding` |
| - | - | - |
| init | - | - |
| 0 | `CrateRoot` | Err(Determined) |
| 1 | `ExternPrelude` | pointing to the `issue_85992_extern_2`(external) |
However, during finalization for `issue_85992_extern_2::Outcome`, the `innermost_result` was pointed to `crate::issue_85992_extern_2` and no ambiguity was generated, leading to a panic.
Attached 2: the state of `early_resolve_ident_in_lexical_scope` during the `finalize_import` for `use issue_85992_extern_2::Outcome` is as follows:
|iter in `visit_scopes` | `scope` | `result.binding` | `innermost_result` |
| - | - | - | - |
| init | - | - | `None` |
| 0 | `CrateRoot` | pointing to `use crate::issue_85992_extern_2` **(introdcued by dummy)** | same as `result` but with a `Some` wapper|
| 1 | `ExternPrelude` | pointing to the `issue_85992_extern_2`(external) | smae as above |
## Try to solve
Skip assertion judgment when `NonModule` is dummy
r? `@petrochenkov`
loongarch: Fix ELF header flags
This patch changes the ELF header flags so that the ABI matches the floating-point features. It also updates the link to the new official documentation.
No need to distinguish `LocalTy` from `Ty`
I think the distinction between `decl_ty` and `revealed_ty` was from when you were allowed to put `impl Trait` in let bindings... I don't think we need that anymore, and it makes typeck that much more confusing 😆
Side-note: I don't know why we store this in a separate field [`locals`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir_typeck/struct.Inherited.html#structfield.locals) in `Inherited`, rather than just the `TypeckResults`... Might look into changing that next.
linker flavors
- only the stable values for `-Clink-self-contained` can be used on stable until we
have more feedback on the interface
- `-Zunstable-options` is required to use unstable linker flavors
Fix unset e_flags in ELF files generated for AVR targets
Closes#106576
~~Sort-of blocked by gimli-rs/object#500~~ (merged)
I'm not sure whether the list of AVR CPU names is okay here. Maybe it could be moved out-of-line to improve the readability of the function.
Use structured suggestion when telling user about `for<'a>`
```
error[E0637]: `&` without an explicit lifetime name cannot be used here
--> $DIR/E0637.rs:13:13
|
LL | T: Into<&u32>,
| ^ explicit lifetime name needed here
|
help: consider introducing a higher-ranked lifetime here
|
LL | T: for<'a> Into<&'a u32>,
| +++++++ ++
```
Encode item bounds for `DefKind::ImplTraitPlaceholder`
This was lost in a refactoring -- `hir::ItemKind::OpaqueTy` doesn't always map to `DefKind::Opaque`, specifically for RPITITs, so the check was migrated subtly wrong, and unfortunately I never had a test for this 🙃Fixes#113155
r? ``@cjgillot``
Account for late-bound vars from parent arg-position impl trait
We should be reporting an error like we do for late-bound args coming from a parent APIT.
Fixes#113016
suggest `slice::swap` for `mem::swap(&mut x[0], &mut x[1])` borrowck error
Recently saw someone ask why this code (example slightly modified):
```rs
fn main() {
let mut foo = [1, 2];
std::mem::swap(&mut foo[0], &mut foo[1]);
}
```
triggers this error and how to fix it:
```
error[E0499]: cannot borrow `foo[_]` as mutable more than once at a time
--> src/main.rs:4:33
|
4 | std::mem::swap(&mut foo[0], &mut foo[1]);
| -------------- ----------- ^^^^^^^^^^^ second mutable borrow occurs here
| | |
| | first mutable borrow occurs here
| first borrow later used by call
|
= help: consider using `.split_at_mut(position)` or similar method to obtain two mutable non-overlapping sub-slices
```
The current help message is nice and goes in the right direction, but I think we can do better for this specific instance and suggest `slice::swap`, which makes this compile
