I refactored the code:
- Removed handling of methods, as it felt entirely unnecessary
- Removed clippy utils (obviously...)
- Used some shiny compiler features
(let-else is very handy for lints 👀)
- I also renamed the lint to `for_loop_over_fallibles` (note: no `s`).
I'm not sure what's the naming convention here, so maybe I'm wrong.
don't ICE when normalizing closure input tys
We were ICEing while rendering diagnostics because `universe_causes` is expected to track every universe created in the typeck's infcx.
`normalize_and_add_constraints` doesn't update `universe_causes`
when creating new universes, causing an ICE. Remove it!
Add spans to better track normalization constraints.
Fix couple places where `universe_causes` is not updated correctly to
track newly added universes.
Fixes#102800
~Fixess #99665~ (UPDATE: no longer true; the issue has a different failure path than when this PR was created and should be fixed by #101708, but the changes in this PR are still correct and should prevent potential future ICEs)
Remove `DefId` from some `SelectionCandidate` variants
They are both from `obligation.predicate.def_id()`, which do not need to be on the `SelectionCandidate`.
cc ````@lcnr```` ````@compiler-errors````
Fix MIR inlining of asm_unwind
The MIR inlining currently doesn't handle inline asm's unwind edge correctly.
This code will cause ICE:
```rust
struct D;
impl Drop for D {
fn drop(&mut self) {}
}
#[inline(always)]
fn foo() {
let _d = D;
unsafe { std::arch::asm!("", options(may_unwind)) };
}
pub fn main() {
foo();
}
```
This PR fixes this issue. I also take the opportunity to extract common code into a method.
Remove `mir::CastKind::Misc`
As discussed in #97649 `mir::CastKind::Misc` is not clear, this PR addresses that by creating a new enum variant for every valid cast.
r? ````@oli-obk````
Rewrite representability
* Improve placement of `Box` in the suggestion
* Multiple items in a cycle emit 1 error instead of an error for each item in the cycle
* Introduce `representability` query to avoid traversing an item every time it is used.
* Also introduce `params_in_repr` query to avoid traversing generic items every time it is used.
`normalize_and_add_constraints` doesn't add entries in `universe_causes`
when creating new universes, causing an ICE. Remove it!
Add spans to track normalization constraints.
Fix couple places where `universe_causes` is not updated correctly to
track newly added universes.
Rollup of 6 pull requests
Successful merges:
- #102300 (Use a macro to not have to copy-paste `ConstFnMutClosure::new(&mut fold, NeverShortCircuit::wrap_mut_2_imp)).0` everywhere)
- #102475 (unsafe keyword: trait examples and unsafe_op_in_unsafe_fn update)
- #102760 (Avoid repeated re-initialization of the BufReader buffer)
- #102764 (Check `WhereClauseReferencesSelf` after all other object safety checks)
- #102779 (Fix `type_of` ICE)
- #102780 (run Miri CI when std::sys changes)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Check `WhereClauseReferencesSelf` after all other object safety checks
This fixes the ICE because it causes us to detect another *non-lint* `MethodViolationCode` first, instead of breaking on `WhereClauseReferencesSelf`.
We could also approach this issue by instead returning a vector of *all* of the `MethodViolationCode`s, and just reporting the first one we see, but treating it as a hard error if we return both `WhereClauseReferencesSelf` and some other violation code -- let me know if this is desired.
Fixes#102762
Remove `-Ztime`
Because it has a lot of overlap with `-Ztime-passes` but is generally less useful. Plus some related cleanups.
Best reviewed one commit at a time.
r? `@davidtwco`
make `compare_const_impl` a query and use it in `instance.rs`
Fixes#88365
the bug in #88365 was caused by some `instance.rs` code using the `PartialEq` impl on `Ty` to check that the type of the associated const in an impl is the same as the type of the associated const in the trait definition. This was wrong for two reasons:
- the check typeck does is that the impl type is a subtype of the trait definition's type (see `mismatched_impl_ty_2.rs` which [was ICEing](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=f6d60ebe6745011f0d52ab2bc712025d) before this PR on stable)
- it assumes that if two types are equal then the `PartialEq` impl will reflect that which isnt true for higher ranked types or type level constants when `feature(generic_const_exprs)` is enabled (see `mismatched_impl_ty_3.rs` for higher ranked types which was [ICEing on stable](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=d7af131a655ed515b035624626c62c71))
r? `@lcnr`
Rollup of 5 pull requests
Successful merges:
- #102672 (rustdoc: remove unused CSS class `in-band`)
- #102693 (Revert "Use getentropy when possible on all Apple platforms")
- #102694 (Suggest calling method if fn does not exist)
- #102708 (Suggest `==` to wrong assign expr)
- #102710 (Add test for issue 82633)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Suggest `==` to wrong assign expr
Given the following code:
```rust
fn main() {
let x = 3;
let y = 3;
if x == x && y = y {
println!("{}", x);
}
}
```
Current output is:
```
error[E0308]: mismatched types
--> src/main.rs:4:18
|
4 | if x == x && y = y {
| ^ expected `bool`, found integer
error[E0308]: mismatched types
--> src/main.rs:4:8
|
4 | if x == x && y = y {
| ^^^^^^^^^^^^^^^ expected `bool`, found `()`
```
This adds a suggestion:
```diff
error[E0308]: mismatched types
--> src/main.rs:6:18
|
6 | if x == x && y = y {
| ^ expected `bool`, found integer
error[E0308]: mismatched types
--> src/main.rs:6:8
|
6 | if x == x && y = y {
| ^^^^^^^^^^^^^^^ expected `bool`, found `()`
|
+ help: you might have meant to compare for equality
+ |
+ 6 | if x == x && y == y {
+ | +
```
And this fixes a part of #97469
Suggest calling method if fn does not exist
I tried to split this up into two commits, the first where we stash the resolution error until typeck (which causes a bunch of diagnostics changes because the ordering of error messages change), then the second commit is the actual logic that actually implements the suggestion.
I am not in love with the presentation of the suggestion, so I could use some advice for how to format the actual messaging.
r? diagnostics
Fixes#102518
`print_time_passes_entry` unconditionally prints data about a pass. The
most commonly used call site, in `VerboseTimingGuard::drop`, guards it
with a `should_print_passes` test. But there are a couple of other call
sites that don't do that test.
This commit moves the `should_print_passes` test within
`print_time_passes_entry` so that all passes are treated equally.
The compiler currently has `-Ztime` and `-Ztime-passes`. I've used
`-Ztime-passes` for years but only recently learned about `-Ztime`.
What's the difference? Let's look at the `-Zhelp` output:
```
-Z time=val -- measure time of rustc processes (default: no)
-Z time-passes=val -- measure time of each rustc pass (default: no)
```
The `-Ztime-passes` description is clear, but the `-Ztime` one is less so.
Sounds like it measures the time for the entire process?
No. The real difference is that `-Ztime-passes` prints out info about passes,
and `-Ztime` does the same, but only for a subset of those passes. More
specifically, there is a distinction in the profiling code between a "verbose
generic activity" and an "extra verbose generic activity". `-Ztime-passes`
prints both kinds, while `-Ztime` only prints the first one. (It took me
a close reading of the source code to determine this difference.)
In practice this distinction has low value. Perhaps in the past the "extra
verbose" output was more voluminous, but now that we only print stats for a
pass if it exceeds 5ms or alters the RSS, `-Ztime-passes` is less spammy. Also,
a lot of the "extra verbose" cases are for individual lint passes, and you need
to also use `-Zno-interleave-lints` to see those anyway.
Therefore, this commit removes `-Ztime` and the associated machinery. One thing
to note is that the existing "extra verbose" activities all have an extra
string argument, so the commit adds the ability to accept an extra argument to
the "verbose" activities.
