Incorrect error "Expected 1 argument, 0 found"

[djc]

I'm on the nightly channel, using VS Code. Since yesterday, I'm seeing this issue:

The row in question is a Row. However, cargo c on the command line thinks my code is fine.

[bjorn3]

Is the type of row correctly inferred? If not this is probably #1791. If the type is not known rust-analyzer guesses what method you meant. In this case it guessed wrong. Before #5283 argument count mismatches were not reported, so there was no error shown.

[djc]

Yeah, the type seems to be correctly inferred, see:

[djc]

Calls to row.get() in this crate (only the one instance causes an incorrect error):

backend/src/documents.rs
75:    let ctype: String = row.get(0);
76:    let bytes: Vec<u8> = row.get(1);

backend/src/assets.rs
58:        let maturity = row.get::<_, NaiveDate>(4);
61:            id: row.get(0),
62:            industry: row.get(2),
63:            sector: row.get(3),
65:            interest_rate_margin: row.get(5),
66:            rating: row.get(6),
67:            esg: (row.get(7), row.get(8)),
68:            level: row.get::<_, Option<Access>>(9),
69:            auditor: row.get(10),
72:        match row.get(1) {
116:    let level = match row.get::<_, Option<Access>>(0) {
127:        name: row.get(0),
141:            id: row.get(0),
142:            name: row.get(1),
143:            uploader: row.get(2),
144:            uploaded: row.get(3),
147:        match row.get(4) {
160:        .map(|row| row.get(0))?;

backend/src/authn.rs
47:        Some(row) => (row.get(0), row.get(1), row.get(2)),
135:            Some(row) => row.get(0),
163:            Some(row) => (row.get(0), row.get(1)),
208:            row.get::<_, &str>(0),

backend/src/lib.rs
62:                .map(|row| row.get::<_, String>(0))

Looks like the reason this is different might be that a non-static lifetime is involved?

[flodiebold]

We ignore lifetimes completely, that's probably not the problem.

Am I reading that right, it says "found 0" even though there is an argument? That's weird.

Also, can you check what the method resolved to?

[djc]

The method also seems to resolve correctly:

[jonas-schievink]

That span looks very odd. It should encompass the entire call expression but seems to stop inside the generic arguments. Would it be possible to get a minimal reproduction of this issue?

[djc]

This is not enough to reproduce:

use tokio_postgres::{Error, NoTls};

#[tokio::main]
async fn main() -> Result<(), Error> {
    let (client, connection) =
        tokio_postgres::connect("host=localhost user=postgres", NoTls).await?;
    tokio::spawn(async move { connection.await.unwrap() });
    let row = client
        .query_one("SELECT $1::TEXT", &[&"hello world"])
        .await?;

    let foo = "hello".to_string();
    let s = format!(
        "https://this.will.make.for.a.very.very.very.long/url/to/append/to/{}/and/more/{}",
        row.get::<_, &str>(0),
        foo,
    );

    bar(&s);
    Ok(())
}

fn bar(_: &str) -> bool {
    true
}

One other interesting thing I noticed: there seems to be a caching issue. If I reload my VS Code window, the error does not show up immediately. Only if I make some edits that result in incorrect syntax it starts showing up, and then doesn't go away again if I correct such errors.

[jonas-schievink]

Hmm, this might not be a bug in the argument count mismatch diagnostic then

[djc]

I bisected this and it seems to have started with 63ce2c7.

[kjeremy]

Did it have 0 arguments at one time? I wonder if the diagnostics are stale.

[ta3pks]

I have the same issue with tokio postgress and the previous version of the rust analyzer seemed to work just fine

[jonas-schievink]

If this happened over the last couple of days, then maybe it was caused by #5481? Which version did this break in?

[kjeremy]

@jonas-schievink that's what I'm wondering...

[kjeremy]

My guess is that we need to grab the file version before the diagnostics start computing because we're probably sending old diagnostics for a newer file version.

Or maybe sending None as the version # would work...