Do not emit note in coerce if loop iterates at least once

[gurry]

Fixes #122561

The fix is a bit conservative. It covers only the cases when it is easy to deduce the loop iteration count such as when the expr iterated over is a range or an array literal. It does not cover more involved cases such as when it is a local, a vec or a method call.

[rustbot]

r? @compiler-errors

rustbot has assigned @compiler-errors.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[compiler-errors]

I don't think we should be suppressing this without replacing it with a better error message and suggestion.

For example, we should explain why Rust doesn't know that 0..10 won't loop at least once, and perhaps we should suggest adding an unreachable!("...") after the loop?

[gurry]

I don't think we should be suppressing this without replacing it with a better error message and suggestion.

For example, we should explain why Rust doesn't know that 0..10 won't loop at least once, and perhaps we should suggest adding an unreachable!("...") after the loop?

Agreed. I'll make the changes.

[bors]

☔ The latest upstream changes (presumably #120926) made this pull request unmergeable. Please resolve the merge conflicts.

[gurry]

Actually, the for loop failing to type check has nothing to do with iteration count. All the three functions shown below, for instance, fail with the exact same type mismatch error even though they have different iteration counts - infinite, finite but non-zero and zero:

fn infinite() -> bool {
   for _i in 0.. {
       return false;
   }
}

fn finite_atleast_once() -> bool {
   for _i in 0..3 {
       return false;
   }
}

fn zero_times() -> bool {
   for _i in 0..0 {
       return false;
   }
}

(Playground: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=49c635d409f3f5bd70031d89d183edf4)

The error actually stems from the for loop desugaring. This is what the bodies of all the above functions desugar to:

fn func()  -> bool {
        {
                let _t =
                    match #[lang = "into_iter"](#[lang = "Range"]{
                                        start: ...,
                                        end: ...,}) {
                            mut iter =>
                                loop {
                                        match #[lang = "next"](&mut iter) {
                                                #[lang = "None"] {} => break,
                                                #[lang = "Some"] {  0: i } => { return false; }
                                            }
                                    },
                        };
                _t
            }
    }

As you can see, the type of the tail expr _t here in will always be () and therefore we will always get the type mismatch error between () and bool irrespective of iteration count.

Given that, the current note, the function expects a value to always be returned, but loops might run zero times, is wrong and misleading. The right fix here therefore is to remove this note (and the related notes) and replace it with something that correctly identifies the problem without being too jargon-y for the user.

I will open a different PR with that change and close this one.

[gurry]

I will open a different PR with that change and close this one.

Here's the new PR: #123125