After closing vscode and reopening the project Rust analyzer fails to locate a module

editors and IDEs
1

Hello,

Yesterday I worked on a project with this structure:
Rust analyzer worked. I shut down my IDE (vscode) and the terminal session and reopened both today. Now I get a tooltip message when hovering over the code within the vm/mod.rs file:
This file is not included anywhere in the module tree, so rust-analyzer can't offer IDE services.
But I do not understand what could be the issue in the structure of my project. It is as the Rust book instructs.
Does anyone have an idea?

// lib.rs
pub mod vm;

src/
-vm/
-- mod.rs
-lib.rs
-main.rs
2

Did you look up in here? Rust analyzer reports "file not included in module tree" but code compiles · Issue #9410 · rust-lang/rust-analyzer · GitHub

Edits:

I don't use vscode, but for example, one reply says:

The problem went away when I reloaded the rust-analyzer.

In another case this might work:

For anyone having similar issues ending up here like me. I fixed it by deleting the .vscode folder in my project. For some reason it was referencing a module I had deleted.

1 Like
3

Why do you still use mod.rs files? When my memory is not too wrong, the official book recommends to use the new project structure, so avoiding mod.rs files? I think the only use case for mod.rs in modern Rust is, for unit tests, when working with common submodules.

4

I read somewhere on here that although the "new version" is to use modname.rs some argue that it is harder to see the module structure of the project by looking at the directory structure.
I first used the "new approach" but found it indeed simpler to use mod.rs files.

5

One problem with the mod.rs files is, that you might have many identically named files in different folders, which might confuse you and your tools. But well, it should work still.

6

Thanks. Restarting rust analyzer did not work however, changing to the "new" module stucture instead of mod.rs files did the trick :slight_smile:

7

It should work if you search a little more, or try the other solutions. Many legacy projects will still have the old structure.

I have not tried this, but it may be helpful if you use what seems less intuitive structure to you: GitHub - regexident/cargo-modules: Visualize/analyze a Rust crate's internal structure

8

At one time that was true, but people objected and it is no longer true. Neither structure is recommended over the other and there is no consensus on which is best. Unfortunately the book still uses the term "idiomatic" for the newer style.

9

Thanks for this info. Actually I don't like the term "idiomatic" that much, its meaning can be "doing something in some way without having a reason". In programming it is good to have a reason. But the argument that many mod.rs files can be confusing makes some sense for me, and I think I have seen this argument not only in the official books.

10

Yes, that is in the book. But people have counterarguments (multiple mod.rs files don't cause problems for me) and there are advantages of the older approach (all files for a module are in a single directory). Tokio notably uses the older approach and Tokio devs argue it is better.

11

Thanks -- I will check my own book, I might advertise the new structure too much :frowning:

1 Like