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...

[0x8f701]

same here, I didn't have this issue three days ago

[kjeremy]

If you change the version to None here does it fix the problem?

https://github.com/rust-analyzer/rust-analyzer/blob/14a3a713c74108626fe356dad21d93b84792878a/crates/rust-analyzer/src/main_loop.rs#L318

[djc]

This does not fix the problem:

diff --git a/crates/rust-analyzer/src/main_loop.rs b/crates/rust-analyzer/src/main_loop.rs
index e95d4157c..2c7369ba3 100644
--- a/crates/rust-analyzer/src/main_loop.rs
+++ b/crates/rust-analyzer/src/main_loop.rs
@@ -315,7 +315,7 @@ impl GlobalState {
                     .unwrap_or_default();

                 self.send_notification::<lsp_types::notification::PublishDiagnostics>(
-                    lsp_types::PublishDiagnosticsParams { uri: url, diagnostics, version },
+                    lsp_types::PublishDiagnosticsParams { uri: url, diagnostics, version: None },
                 );
             }
         }

[SorteKanin]

Getting a similar thing:

No idea why this would pop up around my use statements. cargo check reports no errors.

[billyrieger]

I'm having the same problem with packed_simd.

[museun]

I've ran into this same issue. It gives the error in two places in the file if I call the function from within a macro (println!()). Once at the beginning of the file and once where the call happens.

#![cfg_attr(debug_assertions, allow(dead_code,))]
use std::{fmt::Debug, str::FromStr};

struct Foo {}

impl Foo {
    fn something<'a, T, M>(&self, input: &str, data: M) -> Result<T, T::Err>
    where
        T: FromStr + Debug,
        T::Err: Debug,
    {
        todo!()
    }
}

#[cfg(test)]
mod tests {
    use super::*;
    #[test]
    fn test_something() {
        let foo = Foo {};
        // let res = foo.something::<usize, _>("foo", ());
        eprintln!("{:#?}", foo.something::<usize, _>("foo", ()));
    }
}

[lnicola]

In the last update you can disable the warning by turning off rust-analyzer.diagnostics.enableExperimental.

[ta3pks]

@lnicola how and where exactly do i do that ? I am using vim-lsp am I supposed to set this in vim lsp settings or something ?

[ta3pks]

apparently you guys broke everything. It doesnt show error messages doesnt suggest auto completion or anything anymore. I had to switch back to rls altough it is muchslower it at least works

[lnicola]

@lnicola how and where exactly do i do that ? I am using vim-lsp am I supposed to set this in vim lsp settings or something ?

Yes, I think it's called diagnostics/enableExperimental.

[flodiebold]

@djc are you still encountering this?

[vorner]

I haven't seen this in a while, but I can't say when exactly it stopped for me.

[djc]

Also haven't seen it in a while, but I haven't been using tokio-postgres that much recently (I no longer have access to the codebase I originally saw this in).

[flodiebold]

Ok, I'll close this then.

[iddm]

I have the same thing right now, using all the latest stuff. It is annoying that rust-analyzer complains but the code compiles just fine.

impl<'a, Allocator, AllocatorError> Iterator for Structa, Allocator>
where
    Allocator: CustomAllocator<Error = AllocatorError>,
{
// ....
}

Compiles just fine, but rust-analyzer throws an error:

trait takes 1 generic argument but 0 generic arguments were supplied
struct.rs(2257, 32): add missing generic argument: `Error, `

Also, it gets an incorrect understanding of the code:

error[E0220]: associated type `Error` not found for `redis_custom_allocator::CustomAllocator`
    --> src/struct.rs:2257:32
     |
2257 |     Allocator: CustomAllocator<Error = AllocatorError>,
     |                                ^^^^^ associated type `Error` not found

Given that the code is:

pub trait CustomAllocator {
    /// The error type returned by the allocator methods.
    type Error;
}