mir: adjust conditional in recursion limit check
Fixes#67552.
This PR adjusts the condition used in the recursion limit check of
the monomorphization collector, from `>` to `>=`.
In #67552, the test case had infinite indirect recursion, repeating a
handful of functions (from the perspective of the monomorphization
collector): `rec` -> `identity` -> `Iterator::count` -> `Iterator::fold`
-> `Iterator::next` -> `rec`.
During this process, `resolve_associated_item` was invoked for
`Iterator::fold` (during the construction of an `Instance`), and
ICE'd due to substitutions needing inference. However, previous
iterations of this recursion would have called this function for
`Iterator::fold` - and did! - and succeeded in doing so (trivially
checkable from debug logging, `()` is present where `_` is in the substs
of the failing execution).
The expected outcome of this test case would be a recursion limit error
(which is present when the `identity` fn indirection is removed), and
the recursion depth of `rec` is increasing (other functions finish
collecting their neighbours and thus have their recursion depths reset).
When the ICE occurs, the recursion depth of `rec` is 256 (which matches
the recursion limit), which suggests perhaps that a different part of
the compiler is using a `>=` comparison and returning a different result
on this recursion rather than what it returned in every previous
recursion, thus stopping the monomorphization collector from reporting
an error on the next recursion, where `recursion_depth_of_rec > 256`
would have been true.
With grep and some educated guesses, we can determine that
the recursion limit check at line 818 in
`src/librustc_trait_selection/traits/project.rs` is the other check that
is using a different comparison. Modifying either comparison to be `>` or
`>=` respectively will fix the error, but changing the monomorphization
collector produces the nicer error.
Fix ICE with explicit late-bound lifetimes
Rather than returning an explicit late-bound lifetime as a generic argument count mismatch (which is not necessarily true), this PR propagates the presence of explicit late-bound lifetimes.
This avoids an ICE that can occur due to the presence of explicit late-bound lifetimes when building generic substitutions by explicitly ignoring them.
r? @varkor
cc @davidtwco (this removes a check you introduced in #60892)
Resolves#72278
Fix diagnostics for `@ ..` binding pattern in tuples and tuple structs
Fixes#72574
Associated https://github.com/rust-lang/rust/pull/72534https://github.com/rust-lang/rust/issues/72373
Includes a new suggestion with `Applicability::MaybeIncorrect` confidence level.
### Before
#### tuple
```
error: `..` patterns are not allowed here
--> src/main.rs:4:19
|
4 | (_a, _x @ ..) => {}
| ^^
|
= note: only allowed in tuple, tuple struct, and slice patterns
error[E0308]: mismatched types
--> src/main.rs:4:9
|
3 | match x {
| - this expression has type `({integer}, {integer}, {integer})`
4 | (_a, _x @ ..) => {}
| ^^^^^^^^^^^^^ expected a tuple with 3 elements, found one with 2 elements
|
= note: expected tuple `({integer}, {integer}, {integer})`
found tuple `(_, _)`
error: aborting due to 2 previous errors
```
#### tuple struct
```
error: `..` patterns are not allowed here
--> src/main.rs:6:25
|
6 | Binder(_a, _x @ ..) => {}
| ^^
|
= note: only allowed in tuple, tuple struct, and slice patterns
error[E0023]: this pattern has 2 fields, but the corresponding tuple struct has 3 fields
--> src/main.rs:6:9
|
1 | struct Binder(i32, i32, i32);
| ----------------------------- tuple struct defined here
...
6 | Binder(_a, _x @ ..) => {}
| ^^^^^^^^^^^^^^^^^^^ expected 3 fields, found 2
error: aborting due to 2 previous errors
```
### After
*Note: final output edited during source review discussion, see thread for details*
#### tuple
```
error: `_x @` is not allowed in a tuple
--> src/main.rs:4:14
|
4 | (_a, _x @ ..) => {}
| ^^^^^^^ is only allowed in a slice
|
help: replace with `..` or use a different valid pattern
|
4 | (_a, ..) => {}
| ^^
error[E0308]: mismatched types
--> src/main.rs:4:9
|
3 | match x {
| - this expression has type `({integer}, {integer}, {integer})`
4 | (_a, _x @ ..) => {}
| ^^^^^^^^^^^^^ expected a tuple with 3 elements, found one with 1 element
|
= note: expected tuple `({integer}, {integer}, {integer})`
found tuple `(_,)`
error: aborting due to 2 previous errors
```
#### tuple struct
```
error: `_x @` is not allowed in a tuple struct
--> src/main.rs:6:20
|
6 | Binder(_a, _x @ ..) => {}
| ^^^^^^^ is only allowed in a slice
|
help: replace with `..` or use a different valid pattern
|
6 | Binder(_a, ..) => {}
| ^^
error[E0023]: this pattern has 1 field, but the corresponding tuple struct has 3 fields
--> src/main.rs:6:9
|
1 | struct Binder(i32, i32, i32);
| ----------------------------- tuple struct defined here
...
6 | Binder(_a, _x @ ..) => {}
| ^^^^^^^^^^^^^^^^^^^ expected 3 fields, found 1
error: aborting due to 2 previous errors
```
r? @estebank
Don't bail out of trait selection when predicate references an error
Fixes#72590
With PR #70551, observing a `ty::Error` guarantees that compilation is
going to fail. Therefore, there are no soundness impliciations to
continuing on when we encounter a `ty::Error` - we can only affect
whether or not additional error messags are emitted.
By not bailing out, we avoid incorrectly determining that types are
`!Sized` when a type error is present, which allows us to avoid emitting
additional spurious error messages.
The original comment mentioned this code being shared by coherence -
howver, this change resulted in no diagnostic changes in any of the
existing tests.
Make pointer offset methods/intrinsics const
Implements #71499 using [the implementations from miri](52f5d202bd/src/shims/intrinsics.rs (L96-L112)).
I added some tests what's allowed and what's UB. Let me know if any other cases should be added.
CC: @RalfJung @oli-obk
Warn about unused captured variables
Include captured variables in liveness analysis. Warn when captured variables
are unused (but possibly read or written to). Warn about dead assignments to
captured variables.
Fixes#37707.
Fixes#47128.
Fixes#63220.
Suggest using std::mem::drop function instead of explicit destructor call
I would prefer to give a better suggestion that includes code example, but I'm currently stuck on getting the correct span for that.
Closes#72322.
rustc_lint: Remove `unused_crate_dependencies` from the `unused` group
Fixes https://github.com/rust-lang/rust/issues/72686
It's undesirable to enable `unused_crate_dependencies` with blanket `#![deny(unused)]` due to the amount of redundant `--extern` options passed by Cargo.
Add test for #66930Closes#66930Closes#67558
They're fixed by #72424.
I skipped adding `--emit=mir` flag to src/test/ui/issues/issue-25145.rs as a regression test since the root cause seems the same and it should be run with `check-pass`, not `run-pass` so we should duplicate that test.
r? @RalfJung
This commit introduces a `Limit` type which is used to ensure that all
comparisons against limits within the compiler are consistent (which can
result in ICEs if they aren't).
Signed-off-by: David Wood <david@davidtw.co>
This commit adjusts the condition used in the recursion limit check of
the monomorphization collector, from `>` to `>=`.
In #67552, the test case had infinite indirect recursion, repeating a
handful of functions (from the perspective of the monomorphization
collector): `rec` -> `identity` -> `Iterator::count` -> `Iterator::fold`
-> `Iterator::next` -> `rec`.
During this process, `resolve_associated_item` was invoked for
`Iterator::fold` (during the construction of an `Instance`), and
ICE'd due to substitutions needing inference. However, previous
iterations of this recursion would have called this function for
`Iterator::fold` - and did! - and succeeded in doing so (trivially
checkable from debug logging, `()` is present where `_` is in the substs
of the failing execution).
The expected outcome of this test case would be a recursion limit error
(which is present when the `identity` fn indirection is removed), and
the recursion depth of `rec` is increasing (other functions finish
collecting their neighbours and thus have their recursion depths reset).
When the ICE occurs, the recursion depth of `rec` is 256 (which matches
the recursion limit), which suggests perhaps that a different part of
the compiler is using a `>=` comparison and returning a different result
on this recursion rather than what it returned in every previous
recursion, thus stopping the monomorphization collector from reporting
an error on the next recursion, where `recursion_depth_of_rec > 256`
would have been true.
With grep and some educated guesses, we can determine that
the recursion limit check at line 818 in
`src/librustc_trait_selection/traits/project.rs` is the other check that
is using a different comparison. Modifying either comparison to be `>` or
`>=` respectively will fix the error, but changing the monomorphization
collector produces the nicer error.
Signed-off-by: David Wood <david@davidtw.co>
