Interaction with `mismatched-lifetime-syntaxes` lint

[traviscross]

It's not entirely clear to me whether this is an issue for r-a or whether we should be feeding something to r-a differently from the rustc side, but let's start here.

In Rust 1.89, we're shipping a mismatched-lifetime-syntaxes lint (docs). See:

• Reword mismatched-lifetime-syntaxes text based on feedback rust#143914
• Add a new mismatched-lifetime-syntaxes lint rust#138677
• Split elided_lifetime_in_paths into finer-grained lints rust#120808 (comment)

If the user starts with the following,

#![allow(unused)]
struct W<'a>(&'a ());
fn f(x: &()) -> W { W(x) }

we emit, from rustc, this diagnostic:

warning: hiding a lifetime that's elided elsewhere is confusing
 --> src/main.rs:3:9
  |
3 | fn f(x: &()) -> W { W(x) }
  |         ^^^     - the same lifetime is hidden here
  |         |
  |         the lifetime is elided here
  |
  = help: the same lifetime is referred to in inconsistent ways, making the signature confusing
  = note: `#[warn(mismatched_lifetime_syntaxes)]` on by default
help: use `'_` for type paths
  |
3 | fn f(x: &()) -> W<'_> { W(x) }
  |                  ++++

As above, we want the user to end up with:

fn f(x: &()) -> W<'_> { W(x) }

However, under r-a (latest nightly rustc + r-a current master), the following happens. Going to the first warning puts the cursor here:

fn f(x: &()) -> W { W(x) }
//      ^

With the cursor there, no code suggestion is available to be applied at all. If we move one character further,

fn f(x: &()) -> W { W(x) }
//       ^

then there's one code suggestion available, and it does this,

fn f(x: &'_ ()) -> W<'_> { W(x) }

which isn't what we want.

If we put the cursor here,

fn f(x: &()) -> W { W(x) }
//              ^

we again don't get a relevant code suggestion (we get the ones about wrapping the return type in Option or Result). If we move one character later, to here,

fn f(x: &()) -> W { W(x) }
//               ^

then we do get the suggestion we want first (and the other one we probably don't want second). That will give us,

fn f(x: &()) -> W<'_> { W(x) }

as desired.

But, of course, how would the user know to put the cursor there? That's not where the user is going to put the cursor to try to make this warning go away.

What do we think?

cc @shepmaster @Veykril

[lnicola]

I think this is the location of the (, isn't it?

      {
        "children": [],
        "code": null,
        "level": "help",
        "message": "one option is to consistently use `'_`",
        "rendered": null,
        "spans": [
          {
            "byte_end": 49,
            "byte_start": 49,
            "column_end": 10,
            "column_start": 10,
            "expansion": null,
            "file_name": "src/main.rs",
            "is_primary": true,
            "label": null,
            "line_end": 3,
            "line_start": 3,
            "suggested_replacement": "'_ ",
            "suggestion_applicability": "MaybeIncorrect",
            "text": [
              {
                "highlight_end": 10,
                "highlight_start": 10,
                "text": "fn f(x: &()) -> W {"
              }
            ]
          }

It's interesting that cargo check doesn't produce that message, but cargo check --message-format=json does.

[shepmaster]

It's interesting that cargo check doesn't produce that message, but cargo check --message-format=json does.

The lint outputs a number of possible solutions, but only the first is shown to a user on the command line. All subsequent suggestions are marked as tool-only.