Error on DMatrix::zeros(rows, cols)

[vadixidav]

For me (on current weekly version), this version introduced a regression that causes DMatrix to be picked up incorrectly when using DMatrix::zeros(). It claims that there is no arguments:

However, a cargo check passes just fine, and I am actually building and running this code currently as part of another program, so it is certain that it does work. In fact, the last version did not have this issue.

My suspicion is that it is incorrectly picking up the first Matrix::zeros(). Nalgebra has four definitions of zeros() on Matrix, each of which may be used depending on which dimensions are Dynamic or which impl DimName.

I will let everyone know if this issue goes away on Monday.

[vadixidav]

The issue still persists, even in the latest release from Monday (which I only installed today).

[vihdzp]

This issue still persists. The following code compiles just fine, but rust-analyzer claims an argument mismatch.

fn main() {
    println!("{}", nalgebra::DMatrix::<i32>::zeros(3, 3));
}

[edwin0cheng]

Seem like this macro invocation expanded incorrectly.

[edwin0cheng]

Wait, there are multiple version of implementation for MatrixMN ...

https://github.com/dimforge/nalgebra/blob/9e625db5382c6eab5541afffe1003f1c512c1edb/src/base/construction.rs

[vadixidav]

This is still occurring to this day. rust-analyzer still seems to be choosing the first implementation on MatrixMN, rather than choosing the correct implementation.

[flodiebold]

#8654 seems to be fixed, but this one still persists. I think the problem is that we don't check trait bounds of the impl during method resolution, so we just choose the first impl.

[digama0]

Here's a minimized version of this test case:

pub trait Trait {}
pub struct Nope;
// impl !Trait for Nope {}   <- because it is not implemented in this crate

pub struct Foo<T>(T);

impl<T: Trait> Foo<T> {
  pub fn foo() -> Self { panic!() }
}

impl Foo<Nope> {
  pub fn foo(_: usize) -> Self { panic!() }
}

fn foo() -> Foo<Nope> {
  Foo::<Nope>::foo(3)
}

It looks like it's a bit different from #11803 after all. In this case the issue is that rustc will exclude the first impl since Nope does not implement Trait, whereas #11803 has to do with the lack of constant evaluation, but the resulting error is similar in that it selects the wrong impl and presents incorrect errors as a result, and if it were to give up instead in this kind of situation then it could avoid the false positive.

[flodiebold]

Yeah, that's what I meant by "we don't check trait bounds of the impl during method resolution" -- we currently only check the trait bounds after selecting the method, but we have to do a preliminary check before selecting it.
If we gave up on ambiguous methods, you're right that we wouldn't produce the false type-mismatch, but we'd produce a false method resolution error instead once we add that 😅 Both are fixes we should make though.

[flodiebold]

Related: #10481.

[xiaohk]

Having the same issue. Is there any workaround that I can use to suspend this error? Thanks!

[H-A-M-G-E-R]

rls has no false positives

[H-A-M-G-E-R]

when i go to definition of zeros(), it's something different

[H-A-M-G-E-R]

it points to

at nalgebra/src/base/construction.rs

/// # Constructors of statically-sized vectors or statically-sized matrices
impl<T: Scalar, R: DimName, C: DimName> OMatrix<T, R, C>
where
    DefaultAllocator: Allocator<T, R, C>,
{
    // TODO: this is not very pretty. We could find a better call syntax.
    impl_constructors!(R, C;                         // Arguments for Matrix<T, ..., S>
    => R: DimName, => C: DimName; // Type parameters for impl<T, ..., S>
    R::name(), C::name();         // Arguments for `_generic` constructors.
    ); // Arguments for non-generic constructors.
}

[okaponta]

This issue seems to happen on all constructor or DMatrix

let dm1 = DMatrix::from_vec(2, 3, vec![0, 1, 2, 3, 4, 5]);
let dm2 = DMatrix::from_diagonal_element(2, 3, 5.0);
let dm3 = DMatrix::<f32>::identity(2, 3);
let dm4 = DMatrix::from_fn(2, 3, |i, j| i * 3 + j);

all is from official example, but it has expected 1 argument, found 3 from rust-analyzer

[contagon]

I can still recreate this as well unfortunately. Let me know if you'd like more info.