Failed Type Annotations in For Loops

[RylanYancey]

** Rust-Analyzer Version:** 0.3.1238-standalone

** Rustc Version:** rustc 1.64.1 (a55dd71d5 2022-09-19)

Rust-Analyzer fails to provide type annotations for variables in loops, giving them the {unknown} type.

Example 1:

    pub fn configure (&mut self, modules: &[Mod]) {

        let mut prev_size = self.input;

        for m in modules.iter() { // problem occurs here; 'm' is of type {unknown}
            self.modules.push((m.init(prev_size, self.batch_size), self.optim.init()));

            prev_size = m.output_size(prev_size);
        }
    }

Example 2:

    pub fn train (&mut self) {
        for data in self.dataset.iter() { // problem occurs here; 'data' is of type {unknown}
            
        }
    }

Issue persists after reinstalling rust-analyzer, restarting VSCode, and restarting my computer. RA successfully identifies the types of other variables.

[Veykril]

Are these functions annotated with an attribute by any chance?

[RylanYancey]

Are these functions annotated with an attribute by any chance?

I'm not sure what that means. I wrote the function myself, it was not generated as part of a trait. Its' just a member function of a struct.

This is what it looks like in my editor

[lnicola]

What type is self.dataset and how does it implement Iterator?

[RylanYancey]

dataset is a Vec<(Tensor, Tensor)>, where Tensors are Vector containers.

[Veykril]

Does this occur for any for loop? Does it work for for pat in [0u32] {}? Does this happen an empty project as well?

[RylanYancey]

I tried for pat in [0u32] {} in two separate projects.

It does not work in existing one, which prompted this post.

It does work in other projects.

Its just the one.

[st3fan]

@RylanYancey Are you able to narrow this down to a minimal project that you can share?

[nobody-famous]

I'm seeing the same thing. It uses whatever type it can infer from how the variable is used inside the loop body.

For this example, hovering over name will show the type as {unknown}.

fn do_stuff(names: &Vec<String>) {
    for name in names {
    }
}

By passing it to a function, it's given the type of the function argument. In this example, hovering now shows name as a String.

fn foo(data: String) {}

fn do_stuff(names: &Vec<String>) {
    for name in names {
        foo(name);
    }
}

In this last example, hovering shows name as a usize. Along with a compiler error saying that's incorrect.

fn foo(data: usize) {}

fn do_stuff(names: &Vec<String>) {
    for name in names {
        foo(name);
    }
}

[Veykril]

We can't do anything here unless we get a proper reproduction + server logs that may help us here.

[nobody-famous]

Apparently it's caused by having my own "core" library in my workspace. My top level Cargo.toml looks like,

[workspace]
members = [
    "runner",
    "core",
]

in runner/Cargo.toml I have core as a dependency,

[dependencies]
core = { path = "../core" }

If I rename that library, or remove the dependency, then the behavior goes away.

[Veykril]

using core as the name for a library is bad choice in general, as it clashes with the standard libraries core (r-a is particularly bad at handling this, but other tools aren't too fond of it either)