Add `IntoIterator` for `Box<[T]>` + edition 2024-specific lints
* Adds a similar method probe opt-out mechanism to the `[T;N]: IntoIterator` implementation for edition 2021.
* Adjusts the relevant lints (shadowed `.into_iter()` calls, new source of method ambiguity).
* Adds some tests.
* Took the liberty to rework the logic in the `ARRAY_INTO_ITER` lint, since it was kind of confusing.
Based mostly off of #116607.
ACP: rust-lang/libs-team#263
References #59878
Tracking for Rust 2024: https://github.com/rust-lang/rust/issues/123759
Crater run was done here: https://github.com/rust-lang/rust/pull/116607#issuecomment-1770293013
Consensus afaict was that there is too much breakage, so let's do this in an edition-dependent way much like `[T; N]: IntoIterator`.
Follow-up fixes to `report_return_mismatched_types`
Some renames, simplifications, fixes, etc. Follow-ups to #123804. I don't think it totally disentangles this code, but it does remove some of the worst offenders on the "I am so confused" scale (e.g. `get_node_fn_decl`).
track cycle participants per root
The search graph may have multiple roots, e.g. in
```
A :- B
B :- A, C
C :- D
D :- C
```
we first encounter the `A -> B -> A` cycle which causes `A` to be a root. We then later encounter the `C -> D -> C` cycle as a nested goal of `B`. This cycle is completely separate and `C` will get moved to the global cache. This previously caused us to use `[B, D]` as the `cycle_participants` for `C` and `[]` for `A`.
split off from #125167 as I would like to merge this change separately and will rebase that PR on top of this one. There is no test for this issue and I don't quite know how to write one. It is probably worth it to generalize the search graph to enable us to write unit tests for it.
r? `@compiler-errors`
Note for E0599 if shadowed bindings has the method.
implement #123558
Use a visitor to find earlier shadowed bingings which has the method.
r? ``@estebank``
Remove libc from MSVC targets
``@ChrisDenton`` started working on a project to remove libc from Windows MSVC targets. I'm completing that work here.
The primary change is to cfg out the dependency in `library/`. And then there's a lot of test patching. Happy to separate this more if people want.
Update `unexpected_cfgs` lint for Cargo new `check-cfg` config
This PR updates the diagnostics output of the `unexpected_cfgs` lint for Cargo new `check-cfg` config.
It's a simple and cost-less alternative to the build-script `cargo::rustc-check-cfg` instruction.
```toml
[lints.rust]
unexpected_cfgs = { level = "warn", check-cfg = ['cfg(foo, values("bar"))'] }
```
This PR also adds a Cargo specific section regarding check-cfg and Cargo inside rustc's book (motivation is described inside the file, but mainly check-cfg is a rustc feature not a Cargo one, Cargo only enabled the feature, it does not own it; T-cargo even considers the `check-cfg` lint config to be an implementation detail).
This PR also updates the links to refer to that sub-page when using Cargo from rustc.
As well as updating the lint doc to refer to the check-cfg docs.
~**Not to be merged before https://github.com/rust-lang/cargo/pull/13913 reaches master!**~ (EDIT: merged in https://github.com/rust-lang/rust/pull/125237)
`@rustbot` label +F-check-cfg
r? `@fmease` *(feel free to roll)*
Fixes https://github.com/rust-lang/rust/issues/124800
cc `@epage` `@weihanglo`
coverage: Memoize and simplify counter expressions
When creating coverage counter expressions as part of coverage instrumentation, we often end up creating obviously-redundant expressions like `c1 + (c0 - c1)`, which is equivalent to just `c0`.
To avoid doing so, this PR checks when we would create an expression matching one of 5 patterns, and uses the simplified form instead:
- `(a - b) + b` → `a`.
- `(a + b) - b` → `a`.
- `(a + b) - a` → `b`.
- `a + (b - a)` → `b`.
- `a - (a - b)` → `b`.
Of all the different ways to combine 3 operands and 2 operators, these are the patterns that allow simplification.
(Some of those patterns currently don't occur in practice, but are included anyway for completeness, to avoid having to add them later as branch coverage and MC/DC coverage support expands.)
---
This PR also adds memoization for newly-created (or newly-simplified) counter expressions, to avoid creating duplicates.
This currently makes no difference to the final mappings, but is expected to be useful for MC/DC coverage of match expressions, as proposed by https://github.com/rust-lang/rust/pull/124278#issuecomment-2106754753.
Suggest setting lifetime in borrowck error involving types with elided lifetimes
```
error: lifetime may not live long enough
--> $DIR/ex3-both-anon-regions-both-are-structs-2.rs:7:5
|
LL | fn foo(mut x: Ref, y: Ref) {
| ----- - has type `Ref<'_, '1>`
| |
| has type `Ref<'_, '2>`
LL | x.b = y.b;
| ^^^^^^^^^ assignment requires that `'1` must outlive `'2`
|
help: consider introducing a named lifetime parameter
|
LL | fn foo<'a>(mut x: Ref<'a, 'a>, y: Ref<'a, 'a>) {
| ++++ ++++++++ ++++++++
```
As can be seen above, it currently doesn't try to compare the `ty::Ty` lifetimes that diverged vs the `hir::Ty` to correctly suggest the following
```
help: consider introducing a named lifetime parameter
|
LL | fn foo<'a>(mut x: Ref<'_, 'a>, y: Ref<'_, 'a>) {
| ++++ ++++++++ ++++++++
```
but I believe this to still be an improvement over the status quo.
Fix#40990.
Fix `tests/debuginfo/strings-and-strs`.
It fails on my machine because it embeds pointer addresses in the expected output.
This commit replaces the addresses with `0x[...]`.
r? ```@Mark-Simulacrum```
defrost `RUST_MIN_STACK=ice rustc hello.rs`
I didn't think too hard about testing my previous PR rust-lang/rust#122847 which makes our stack overflow handler assist people in discovering the `RUST_MIN_STACK` variable (which apparently is surprisingly useful for Really Big codebases). After it was merged, some useful comments left in a drive-by review led me to discover I had added an ICE. This reworks the code a bit to explain the rationale, remove the ICE that I introduced, and properly test one of the diagnostics.
fix suggestion in E0373 for !Unpin coroutines
Coroutines can be prefixed with the `static` keyword to make them
`!Unpin`.
However, given the following function:
```rust
fn check() -> impl Sized {
let x = 0;
#[coroutine]
static || {
yield;
x
}
}
```
We currently suggest prefixing `move` before `static`, which is
syntactically incorrect:
```
error[E0373]: coroutine may outlive the current function, but it borrows
...
--> src/main.rs:6:5
|
6 | static || {
| ^^^^^^^^^ may outlive borrowed value `x`
7 | yield;
8 | x
| - `x` is borrowed here
|
note: coroutine is returned here
--> src/main.rs:6:5
|
6 | / static || {
7 | | yield;
8 | | x
9 | | }
| |_____^
help: to force the coroutine to take ownership of `x` (and any other
referenced variables), use the `move` keyword
| // this is syntactically incorrect, it should be `static move ||`
6 | move static || {
| ++++
```
This PR suggests adding `move` after `static` for these coroutines.
I also added a UI test for this case.
Never type unsafe lint improvements
- Move linting code to a separate method
- Remove mentions of `core::convert::absurd` (#124311 was rejected)
- Make the lint into FCW
The last thing is a bit weird though. On one hand it should be `EditionSemanticsChange(2024)`, but on the other hand it shouldn't, because we also plan to break it on all editions some time later. _Also_, it's weird that we don't have `FutureReleaseSemanticsChangeReportInDeps`, IMO "this might cause UB in a future release" is important enough to be reported in deps...
IMO we ought to have three enums instead of [`FutureIncompatibilityReason`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint_defs/enum.FutureIncompatibilityReason.html#):
```rust
enum IncompatibilityWhen {
FutureRelease,
Edition(Edition),
}
enum IncompatibilyWhat {
Error,
SemanticChange,
}
enum IncompatibilityReportInDeps {
No,
Yes,
}
```
Tracking:
- https://github.com/rust-lang/rust/issues/123748
An earlier commit included the change for a suggestion here.
Unfortunately, it also used unwrap instead of dying properly.
Roll out the ~~rice paper~~ EarlyDiagCtxt before we do anything that
might leave a mess.
bors