Add beginner friendly lifetime elision hint to E0623

[Noratrieb]

Address #90170

Suggest adding a new lifetime parameter when two elided lifetimes should match up but don't.

Example:

error[E0623]: lifetime mismatch
  --> $DIR/issue-90170-elision-mismatch.rs:2:35
   |
LL | fn foo(slice_a: &mut [u8], slice_b: &mut [u8]) {
   |                 ---------           --------- these two types are declared with different lifetimes...
LL |     core::mem::swap(&mut slice_a, &mut slice_b);
   |                                   ^^^^^^^^^^^^ ...but data from `slice_b` flows into `slice_a` here
   |
   = note: each elided lifetime in input position becomes a distinct lifetime
help: explicitly declare a lifetime and assign it to both
   |
LL | fn foo<'a>(slice_a: &'a mut [u8], slice_b: &'a mut [u8]) {
   |       ++++           ++                     ++

for

fn foo(slice_a: &mut [u8], slice_b: &mut [u8]) {
    core::mem::swap(&mut slice_a, &mut slice_b);
}

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @estebank (or someone else) soon.

Please see the contribution instructions for more information.

[estebank]

Thank you so much for doing this! It is great! I have some nitpicks below, but none of them are a dealbreaker. Would you have time to address them?

[Noratrieb]

I will remove the tests that cause the double error reporting so that rustfix can apply the correct fix for all test cases. I'll add some other ones that shoudn't have this issue but test the new suggestions just as well.

[estebank]

@bors r+

[bors]

📌 Commit 76ec1aa has been approved by estebank

[matthiaskrgr]

Some tests failed in a rollup: #90325 (comment)
@bors r-

[Noratrieb]

I'm a bit confused about why the rollup failed, I updated my fork and my local repository, I have the most recent commit of master, but the tests pass.

[estebank]

Have you tried doing git checkout master && git pull && git checkout lifetime-elision-mismatch-hint && git rebase master and then rerunning --bless?

[Noratrieb]

I tried it now, the tests still pass and --bless doesn't change anything.

[estebank]

Can you run ./x.py test src/test/ui --bless --compare-mode=nll?

[Noratrieb]

I ran it, the test still passed.

I also cloned my fork into a fresh directory again and rebuilt everything, but the lifetime tests still pass.

[estebank]

Even with --compare-mode=nll? That's super weird. :(

[Noratrieb]

Yes, even with the flag

[Noratrieb]

Should we try to include this in the next rollup again and see whether it works, or what's your idea for it?

[matthiaskrgr]

@bors retry rollup=iffy

[Noratrieb]

:(

[lqd]

Repeating my comment from zulip here in case you missed it.

This PR adds a new test, and it apparently has different diagnostics under NLL, making the PR fail as you've noticed in the previous comments. The fact that the command Esteban showed works on your machine makes me think that you could locally have the file that the UI tests expect ?

That command should have created a src/test/ui/lifetimes/issue-90170-elision-mismatch.nll.stderr file, can you check if you have it ?

[Noratrieb]

Also repeat from zulip

Oh I think I just found the issue. Two tests have always been failing (ui/linkage-attr/issue-10755.rs and ui/process/process-spawn-nonexistent.rs) (I should probably open an issue) so I've just been ignoring that fact. I just added the ignore-test attribute to them and turns out, there is some more stuff that is ran after they fail, for example thje NLL tests. I've now got the .nll.stderr and I hope this will fix everything! Oh man this is so dumb, but I'm glad that I finally fixed it, thank you for your help!

[Noratrieb]

oops, that was an accident

[Noratrieb]

i hope i fixed everything, I'm sorry that the last commit is now on top, but it's gits fault for making rebase conflicts so weird :(

[estebank]

Last nitpick: if you do a rebase again and squash all commits into one, it will be easier to look at the involved files history in the future and there will be no longer any "weird log history". I normally leave the commits independent during review and squash into commits containing logical grouped changes. In this case a single commit should be fine. If you try locally and find difficulties doing this, don't worry, let me know and I'll merge as is, but I'd prefer squashing these.

[Noratrieb]

So, that's it, let's hope this finally works!😅

[estebank]

@bors r+

[bors]

📌 Commit 4b9e460 has been approved by estebank

[bors]

⌛ Testing commit 4b9e460 with merge e60e19b...

[bors]

☀️ Test successful - checks-actions
Approved by: estebank
Pushing e60e19b to master...

[rust-timer]

Finished benchmarking commit (e60e19b): comparison url.

Summary: This benchmark run did not return any relevant changes.

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression