Let chains tests
Filing this as this marks off two of the open issues in #132833:
* extending the tests for `move-guard-if-let-chain.rs` and `conflicting_bindings.rs` to have chains with multiple let's (one implementation could for example search for the first `let` and then terminate).
* An instance where a temporary lives shorter than with nested ifs, breaking compilation: #103476. This was fixed in the end by the if let rescoping work.
Closes #103476
Trim whitespace in RemoveLet primary span
Separate `RemoveLet` span into primary span for `let` and removal suggestion span for `let `, so that primary span does not include whitespace.
Fixes: #133031
Increase accuracy of `if` condition misparse suggestion
Fix #132656.
Look at the expression that was parsed when trying to recover from a bad `if` condition to determine what was likely intended by the user beyond "maybe this was meant to be an `else` body".
```
error: expected `{`, found `map`
--> $DIR/missing-dot-on-if-condition-expression-fixable.rs:4:30
|
LL | for _ in [1, 2, 3].iter()map(|x| x) {}
| ^^^ expected `{`
|
help: you might have meant to write a method call
|
LL | for _ in [1, 2, 3].iter().map(|x| x) {}
| +
```
If a macro statement has been parsed after `else`, suggest a missing `if`:
```
error: expected `{`, found `falsy`
--> $DIR/else-no-if.rs:47:12
|
LL | } else falsy! {} {
| ---- ^^^^^
| |
| expected an `if` or a block after this `else`
|
help: add an `if` if this is the condition of a chained `else if` statement
|
LL | } else if falsy! {} {
| ++
```
Querify MonoItem collection
Factored out of https://github.com/rust-lang/rust/pull/131650. These changes are required for post-mono MIR opts, because the previous implementation would load the MIR for every Instance that we traverse (as well as invoke queries on it). The cost of that would grow massively with post-mono MIR opts because we'll need to load new MIR for every Instance, instead of re-using the `optimized_mir` for every Instance with the same DefId.
So the approach here is to add two new queries, `items_of_instance` and `size_estimate`, which contain the specific information about an Instance's MIR that MirUsedCollector and CGU partitioning need, respectively. Caching these significantly increases the size of the query cache, but that's justified by our improved incrementality (I'm sure walking all the MIR for a huge crate scales quite poorly).
This also changes `MonoItems` into a type that will retain the traversal order (otherwise we perturb a bunch of diagnostics), and will also eliminate duplicate findings. Eliminating duplicates removes about a quarter of the query cache size growth.
The perf improvements in this PR are inflated because rustc-perf uses `-Zincremental-verify-ich`, which makes loading MIR a lot slower because MIR contains a lot of Spans and computing the stable hash of a Span is slow. And the primary goal of this PR is to load less MIR. Some squinting at `collector profile_local perf-record +stage1` runs suggests the magnitude of the improvements in this PR would be decreased by between a third and a half if that flag weren't being used. Though this effect may apply to the regressions too since most are incr-full and this change also causes such builds to encode more Spans.
Update cdb annotations for some debuginfo tests with cdb `10.0.26100.2161`
GitHub CI runners [recently updated to Windows Server 2022 (20241113)](https://github.com/actions/runner-images/releases/tag/win22%2F20241113.3) which included Windows Software Development Kit version `10.1.26100.1742`, which transitively shipped a `cdb` version `10.0.26100.2161`.
This changed some cdb output, causing 3 debuginfo tests to fail (see #133107, https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/msvc.20update.20causing.20debuginfo.20failures):
```
tests\debuginfo\numeric-types.rs
tests\debuginfo\range-types.rs
tests\debuginfo\unit-type.rs
```
I updated cdb annotations for these 3 tests locally with a matching `cdb` version. However, I am not by any means a cdb expert nor debuginfo expert, I just reblessed the tests to match whatever the new cdb version produces to unblock the tree. It is certainly possible that debuginfo improved/regressed/both with the newer cdb version.
try-job: x86_64-msvc
This is to unblock the tree, a proper fix will need to be investigated.
I think the debuginfo test suite supports revisions, however debugger
directives do not respect such revisions, which is problematic.
It's that 32-bit and 64-bit msvc of course have different integer widths
for `isize` and `usize`, meaning their underlying integer is different
and thus printed differently.
Opt out TaKO8Ki from review rotation for now
Hi `@TaKO8Ki,` I'm opting you out from compiler/diagnostics review rotation for now because I *think* you're very busy recently. Please feel free to re-add yourself (or close this PR) whenever you have more time / feel like it.
Deny capturing late-bound ty/const params in nested opaques
First, this reverts a7f609504c. I can't exactly remember why I approved this specific bit of https://github.com/rust-lang/rust/pull/132466; specifically, I don't know that the purpose of that commit is, and afaict we will never have an opaque that captures late-bound params through a const because opaques can't be used inside of anon consts. Am I missing something `@cjgillot?` Since I can't see a case where this matters, and no tests seem to fail.
The second commit adds a `deny_late_regions: bool` to distinguish `Scope::LateBoundary` which should deny *any* late-bound params or just ty/consts. Then, when resolving opaques we wrap ourselves in a `Scope::LateBoundary { deny_late_regions: false }` so that we deny late-bound ty/const, which fixes a bunch of ICEs that all vaguely look like `impl for<T> Trait<Assoc = impl OtherTrait<T>>`.
I guess this could be achieved other ways; for example, with a different scope kind, or maybe we could just reuse `Scope::Opaque`. But this seems a bit more verbose. I'm open to feedback anyways.
Fixes #131535
Fixes #131637
Fixes #132530
I opted to remove those crashes tests ^ without adding them as regular tests, since they're basically triggering uninteresting late-bound ICEs far off in the trait solver, and the reason that existing tests such as `tests/ui/type-alias-impl-trait/non-lifetime-binder-in-constraint.rs` don't ICE are kinda just coincidental (i.e. due to a missing impl block). I don't really feel motivated to add random permutations to tests just to exercise non-lifetime binders.
r? cjgillot
Unify FnKind between AST visitors and make WalkItemKind more straight forward
Unifying `FnKind` requires a bunch of changes to `WalkItemKind::walk` signature so I'll change them in one go
related to #128974
r? `@petrochenkov`
rustdoc search: allow queries to end in an empty path segment
fixes https://github.com/rust-lang/rust/issues/129707
this can be used to show all items in a module,
or all associated items for a type.
currently sufferes slightly due to case insensitivity, so `Option::` will also show items in the `option::` module.
it disables the checking of the last path element, otherwise only items with short names will be shown
r? `@notriddle`
mark is_val_statically_known intrinsic as stably const-callable
The intrinsic doesn't actually "do" anything in terms of language semantics, and we are already using it in stable const fn. So let's just properly mark it as stably const-callable to avoid needing `rustc_allow_const_fn_unstable` (and thus reducing noise and keeping the remaining `rustc_allow_const_fn_unstable` as a more clear signal).
Cc `@rust-lang/lang` usually you have to approve exposing intrinsics in const, but this intrinsic is basically just a compiler implementation detail. So FCP doesn't seem necessary.
Cc `@rust-lang/wg-const-eval`
If a macro statement has been parsed after `else`, suggest a missing `if`:
```
error: expected `{`, found `falsy`
--> $DIR/else-no-if.rs:47:12
|
LL | } else falsy! {} {
| ---- ^^^^^
| |
| expected an `if` or a block after this `else`
|
help: add an `if` if this is the condition of a chained `else if` statement
|
LL | } else if falsy! {} {
| ++
```
Look at the expression that was parsed when trying to recover from a bad `if` condition to determine what was likely intended by the user beyond "maybe this was meant to be an `else` body".
```
error: expected `{`, found `map`
--> $DIR/missing-dot-on-if-condition-expression-fixable.rs:4:30
|
LL | for _ in [1, 2, 3].iter()map(|x| x) {}
| ^^^ expected `{`
|
help: you might have meant to write a method call
|
LL | for _ in [1, 2, 3].iter().map(|x| x) {}
| +
```
Rollup of 5 pull requests
Successful merges:
- #132936 (For expr `return (_ = 42);` unused_paren lint should not be triggered)
- #132956 (Add visit_coroutine_kind to ast::Visitor)
- #132978 (Mention both release *and* edition breakage for never type lints)
- #133074 (make UI test OS-agnostic)
- #133080 (Fix span edition for 2024 RPIT coming from an external macro )
r? `@ghost`
`@rustbot` modify labels: rollup
Fix span edition for 2024 RPIT coming from an external macro
This fixes a problem where code generated by an external macro with an RPIT would end up using the call-site edition instead of the macro's edition for the RPIT. When used from a 2024 crate, this caused the code to change behavior to the 2024 capturing rules, which we don't want.
This was caused by the impl-trait lowering code would replace the span with one marked with `DesugaringKind::OpaqueTy` desugaring. However, it was also overriding the edition of the span with the edition of the local crate. Instead it should be using the edition of the span itself.
Fixes https://github.com/rust-lang/rust/issues/132917
make UI test OS-agnostic
the internal representation of `std::sync::Mutex` depends on the compilation target. due to this, the compiler produces different number of errors for UI test `issue-17431-6.rs` depending on the compilation target.
for example, when compiling the UI test to an `*-apple-*` or `*-qnx7*` target, the "cycle detected" error is not reported
``` console
$ cat src/lib.rs
use std::sync::Mutex;
enum Foo {
X(Mutex<Option<Foo>>),
}
impl Foo {
fn bar(self) {}
}
fn main() {}
$ cargo check --target x86_64-apple-ios 2>&1 | rg '^error\['
error[E0072]: recursive type `Foo` has infinite size
```
whereas rustc produces two errors for other OSes, like Linux, which is what the UI test expects
``` console
$ cargo check --target x86_64-unknown-linux-gnu 2>&1 | rg '^error\['
error[E0072]: recursive type `Foo` has infinite size
error[E0391]: cycle detected when computing when `Foo` needs drop
```
this commit replaces the problematic `Mutex` with `UnsafeCell`, which has the same internal representation regardless of the compilation target. with that change, rustc reports two errors for all compilation targets.
``` console
$ cat src/lib.rs
use std::cell::UnsafeCell;
enum Foo {
X(UnsafeCell<Option<Foo>>),
}
impl Foo {
fn bar(self) {}
}
fn main() {}
$ cargo check --target x86_64-apple-ios 2>&1 | rg '^error\['
error[E0072]: recursive type `Foo` has infinite size
error[E0391]: cycle detected when computing when `Foo` needs drop
```
with this change, we can remove the `ignore-apple` directive as the UI test now also passes on apple targets.
Mention both release *and* edition breakage for never type lints
This PR makes ~~two changes~~ a change to the never type lints (`dependency_on_unit_never_type_fallback` and `never_type_fallback_flowing_into_unsafe`):
1. Change the wording of the note to mention that the breaking change will be made in an edition _and_ in a future release
2. ~~Make these warnings be reported in deps (hopefully the lints are matured enough)~~
r? ``@compiler-errors``
cc ``@ehuss``
closes #132930
