Incorrect resolution of Nalgebra 0.26's fixed-size Vector/Matrix constructors

[Rua]

Nalgebra 0.26 introduced const generics into its types, and rust-analyzer seems to be having trouble resolving or otherwise figuring out its method signatures. To reproduce, create a new project with the following:

Cargo.toml:

[dependencies]
nalgebra = "0.26"

main.rs:

use nalgebra::Vector2;

fn main() {
    let _foo = Vector2::new(1.0, 1.0);
}

cargo check reports no problems, but rust-analyzer in VSCode puts an error on the Vector2 constructor: "Expected 4 arguments, found 2". Vector2 is a type alias in Nalgebra (definition), and its new constructor should have only 2 arguments, as defined here with the Const<2>, Const<1> variant.

Similar errors happen with other fixed-size Matrix type aliases in Nalgebra too. For example, Matrix4::new, which should take 16 values, is reported by rust-analyzer as also requiring 4.

rustc 1.52.0-beta.5
rust-analyzer version: 2021-04-12-92-g7570212a5

[Veykril]

We don't handle const params at all yet, cc #7434

[vilcans]

I can confirm that downgrading to nalgebra 0.25.4 gets rid of the error.

[kettle11]

Is there a way to suppress this class of errors until a more final fix occurs?

Presently my code is littered with erroneous red squiggles.

[flodiebold]

https://rust-analyzer.github.io/manual.html#diagnostics

[kettle11]

https://rust-analyzer.github.io/manual.html#diagnostics

Thanks for the link.

To be clear for others: mismatched-arg-count can be added to the rust-analyzer settings to suppress some of these errors.

The relevant settings look like this in VSCode:

[vadixidav]

This might also be related to #5441. Same error, but that issue I encountered about a year before this one. It seems to be related to the wrong new and zeros implementation being chosen.

[jpetkau]

I don't know if this is helpful but I made a standalone repro before discovering this just wasn't a supported feature.

struct Point<T, const N: usize>([T; N]);
impl<T> Point<T, 2> { pub fn new(_x: T, _y: T) -> Self { todo!() } }
impl<T> Point<T, 3> { pub fn new(_x: T, _y: T, _z: T) -> Self { todo!() } }
type Point3<T> = Point<T, 3>;
fn main() { let _v = Point3::new(1.0, 2.0, 3.0); }

Also, as a workaround in my own code (since the bogus errors were making rust-analyzer unusable in my code), I just wrote wrappers for the problematic constructors and call those instead of the generic ones:

fn vec2<T>(x: T, y: T) -> na::Vector2<T> { [x, y].into() }
fn vec3<T>(x: T, y: T, z: T) -> na::Vector3<T> { [x, y, z].into() }

etc.

Obviously not a long-term solution, but it worked well enough for me for now.

[benbot]

Any idea where to start with this

Sublime shows me this from rust-analyzer.

it's saying that type Point3 = Point<T> which is just flat different than what it actually is.

Would this point to a parsing issue maybe?

[Veykril]

r-a does not yet support const generics properly so it not showing the const argument is expected currently.

[thefakeplace]

I'm just thinking it would be pretty reasonable-- when/if rust-analyzer becomes first-party-- to block language features from entering stable rust until they're supported by rust-analyzer. This is the bar that well-supported languages set.

Having things squiggle out (but compile just fine) is extremely, extremely confusing and discouraging for beginners.

I'm not saying that the effort invested isn't appreciated and, yeah, I realize you probably have no control over this today. Just my two cents for when/if rust-analyzer becomes the first-party LS impl.

[flodiebold]

This works correctly for me now, though #5441 still doesn't.

[lnicola]

This works indeed, although the type hint is pretty ugly:

Tested on nalgebra 0.26 and 0.30.

Closing, please keep an eye on #5441 and/or file new issues if necessary.