I was following chapter 12.3 of the Rust book [0]. Particularly this snippet from Listing 12-14:
use std::env;
use std::process;
use minigrep;
use minigrep::Config;
fn main() {
// --snip--
if let Err(e) = minigrep::run(config) {
// --snip--
}
}
However, the VS Code extension threw me some errors:

Upon digging this issue, I found out that prior to the 2018 Edition, the Rust compiler would have caught these issues [1]. After updating Rust to 1.32.0 and adding edition = "2018" to Cargo.toml, my code ran just fine in the terminal. Yet, these errors still persist inside VS Code via the Rust extension. Is it just me or the extension never fixes this error?
[0] https://doc.rust-lang.org/book/ch12-03-improving-error-handling-and-modularity.html
[1] https://github.com/rust-lang/book/issues/1676#issuecomment-445876415
@tuvtran, I had this same issue with Rust 1.32.0. Upgraded to version 1.33.0 and RLS stopped reporting these false-negatives.
I'm running Rust 1.33.0 and RLS, and am still getting these issues - everything builds and runs fine, but an libraries pulled in from crates can't be resolved in the editor.
Adding extern crate foo fixes the problem in VS Code, so maybe the tooling just hasn't quite caught up? The edition is set to 2018.
Could you post your rust.* VSCode configs and the contents of Cargo.toml? Most recent stable RLS should work, assuming the edition = "2018" is in the Cargo.toml.
@tuvtran, changing the edition = "2018" to another (random) year and then back to 2018 solved the issue for me in VS Code.
@tuvtran I think you need to just change your VSCode theme, when you change everything should be much better.
I had the problem described in the opening post running rustc 1.33.0. Most of my tools, including Rust itself and the Rust VSCode plugins, have been installed not a week ago. The project is freshly created with cargo new and had edition = "2018".
changing the
edition = "2018"to another (random) year and then back to 2018 solved the issue for me in VS Code.
That "fixed" it for me too.
edit:
Correction - it only removed the errors, but it wouldn't autocomplete for minigrep:: and anything inside. I added extern crate minigrep; and now everything works as I'd expect it: No errors and autocomplete.
@Xanewok
Cargo.toml:
[package]
name = "minigrep"
version = "0.1.0"
authors = ["Tobias Wehrum <[email protected]>"]
edition = "2018"
[dependencies]
Where can I find the "rust.* VSCode configs" you wanted? (I'm on Windows 7.)
@TobiasWehrum Hit Ctrl+, and click the "{}" button to the right to open the settings.json, you should have some options changed there.
@Xanewok These is my whole settings.json:
{
"[markdown]": {
},
"editor.formatOnType": true,
"editor.formatOnSave": true,
"terminal.integrated.shell.windows": "C:\\Windows\\System32\\cmd.exe",
"explorer.openEditors.visible": 0,
"editor.suggestSelection": "first",
"vsintellicode.modify.editor.suggestSelection": "automaticallyOverrodeDefaultValue"
}
So I had a simple cargo new t pre-created already with a bare src/lib.rs and src/main.rs and when I added
use t;
use t::MyStruct; // pub struct MyStruct { ... } inside the src/lib.rs
this works as expected.
Could you possibly provide a very detailed, step-by-step reproduction? Do you start with a cargo new --bin project, add a lib.rs separately and then add the import directives?
cargo new t doesn't create a src/lib.rs for me, only a src/main.rs.
cargo new tsrc/lib.rs.pub struct MyStruct {} to lib.rs.src/main.rs.use t::, don't get offered MyStruct by intellisense, remove the line again.extern crate t;.MyStruct.I have this same problem on Windows 10. I see the same behavior with deleting the line and re-typing the use line. I also had the above behavior with changing the year in Cargo.toml and changing it back.
exit vscode and re-open, fixed the issue.
I'm having the exact same issue while running rustc 1.36.0 (a53f9df32 2019-07-03). Adding extern crate doesn't seem to fix anything for me as RLS can't find the crate at all.
These are the errors and warnings I am getting, although none of these show up as I compile and run the program:

I had to follow @fzxu and restart vscode (and by extension RLS)
@tuvtran, changing the
edition = "2018"to another (random) year and then back to 2018 solved the issue for me in VS Code.
I'm using rust v1.35.0 and VSCode 1.36.1 with Rust(rls) plugin v0.6.1. This trick worked for me too.
exit vscode and re-open, fixed the issue.
press <F1> and type Rust: Restart the RLS solved the issue for me.
I tried all proposed solution the linting errors disappear but autocomplete does not work just when I add extern crate minigrep;. Same here as @TobiasWehrum commented before
I also tried everything here and I'm still having this issue.
i use arch btw
Just had this issue recently and a couple of the suggestions worked (changing edition to something else, then back worked; also restarting the RLS worked). Could it be an RLS bug?
I fix it with use crate::<my-mod>
same happens to me with rls nightly and rust 1.40. restarting VS code fixes it.
In VS Code I solve this issue by running the "reload window" command.
Ctrl + shift + p then type "reload window"
None of the previous solutions helped unfortunately.
Basically cargo run works just fine and runs the project. But VSCode can't figure out where crates are:
Code:
use rand::Rng;
fn main() {
let rnd_num = rand::thread_rng().gen_range(1, 100);
println!("Random number: {}", rnd_num);
}
cargo run from terminal:
[jurisl@JurisLinuxPC game]$ cargo run
Finished dev [unoptimized + debuginfo] target(s) in 0.01s
Running `target/debug/game`
Random number: 54
Errors when running from code editor:
error[E0432]: unresolved import `rand`
--> main.rs:1:5
|
1 | use rand::Rng;
| ^^^^ maybe a missing crate `rand`?
error[E0433]: failed to resolve: use of undeclared type or module `rand`
--> main.rs:4:19
|
4 | let rnd_num = rand::thread_rng().gen_range(1, 100);
| ^^^^ use of undeclared type or module `rand`
error: aborting due to 2 previous errors
Some errors have detailed explanations: E0432, E0433.
For more information about an error, try `rustc --explain E0432`.
Adding extern crate rand; results in the same error:
error[E0463]: can't find crate for `rand`
--> main.rs:1:1
|
1 | extern crate rand;
| ^^^^^^^^^^^^^^^^^^ can't find crate
error: aborting due to previous error
For more information about this error, try `rustc --explain E0463`.
Changing edition = "2018" - Does not help.
Restarting RLS/VSCode - Does not help.
NOTE:

Basically, out of two editors (VSCode and Atom), that have Debugging capabilities, unlike Intellij Rust, both don't work for me and I just can't code in Rust as tools are literally broken/not mature enough for productive work. Please let me know if I am wrong and it is just a case of one little flag, that everyone forgets to mention, is missing in some config.
After doing the Reload Window operation, I stop seeing the false-positive errors in the editor, but I do not get symbol completion for symbols in the lib.rs from main.rs (I'm also following the Book and doing the minigrep project.) I do seem to get symbol completion from within the lib.rs file while there though.
@RebelCoderRU I'm getting exactly the same errors as you.
Does your crate compile? I've had the same problem when autocompletion breaks down when there were compile errors in the crate (e.g. missing imports)
I have the same "unresolved import"problem but autocompletion works fine,
Seeing the errors as well, reloading the window fixed the issue for me
FWIW, I am seeing this same issue with RLS in Emacs, so it looks like a language server issue, not a VSCode one. Restarting the server worked for me.
For the record, I just got the same problem (code compiles fine, RLS can't find dependencies) with this loadout:
VIM - Vi IMproved 8.2 (2019 Dec 12, compiled May 31 2020 11:42:24)Included patches: 1-856ALE (revision 2d9380d75c5c27a3241925d24ab3be8977a43207) with the following config via vimrc...
" ...stuff assumed to be irrelevant...
let g:ale_lint_on_text_changed = 'never'
let g:ale_lint_on_insert_leave = 0
(i.e. only lint on save), and the following config via ftplugin/rust.vim:
let b:ale_linters = ['cargo', 'rls']
let b:ale_fixers = ['remove_trailing_lines', 'trim_whitespace']
let g:ale_rust_cargo_use_clippy = executable('cargo-clippy')
let g:ale_rust_rls_config = {
\ 'rust': {
\ 'clippy_preference': executable('cargo-clippy') ? 'on' : 'off'
\ }
\ }
(I won't be running rustfmt automatically until #[rustfmt::skip] is free of errors like error: attributes are not yet allowed on ``if`` expressions)
rls 1.41.0 (5fde462 2020-02-21)
(It's what rustup update stable gave me to match rustc 1.43.1 (8d69840ab 2020-05-04) last time I ran it)
(In other words, it definitely looks like a problem in RLS, not the VSCode extension.)
However, I may have a hint as to how to reproduce the problem and where it comes from.
I don't currently have time to sit through another compile to verify that it'll reproduce it (I'm on an Athlon II X2 270 and have no global compiled dependency caching set up and the test involved actix's ~170 dependencies), but here's what triggered it for me:
cargo new whatevercargo add actix (Note my distracted mistake here)cargo runactix-web and actix-rt, fix Cargo.tomlcargo runCargo.toml, no matter how much you fiddle with :w and :ALEToggle without resorting to killall rls....so a similar dance with adding dependencies might be able to reproduce it under VSCode, and I suspect it's some kind of cache invalidation bug within RLS.
The issue still exists (as I came across the same situation https://github.com/rust-lang/vscode-rust/issues/513#issue-414302862 )
And operations like reopening VS Code can magically fix that 馃ぃ Maybe rust is true magic
@SeanChao Yeah still got the problem here, restarting the rust language server works. The error keeps coming back. I ended up just adding a hotkey if I _know_ that the import works and just hit it. The language server takes milliseconds to restart, if you have lots of imports your VSCode may take a second or two to catch up.
I am getting this error as well, but none of the above proposed solutions fix my issue.

api/mod.rs is clearly there. I get this same issue on my Windows machine as well. It is literally the only file not working, all the others work just fine.
me too..
exit vscode and re-open, fixed the issue.
馃ぃ When people have computer problems I often just roll my eyes and tell them "have you tried restarting?", and the problem is usually gone. But I can never remember my own advice when it's my own turn.
This error is still reproducible, setup: VS Code (1.54.3), rustc 1.49.0 (e1884a8e3 2020-12-29), wsl 2 (Windows, but .. wsl 2, so ubuntu).
@alessioalex Agreed using WSL2 as well and this issue is very annoying lol
Most helpful comment
@tuvtran, changing the
edition = "2018"to another (random) year and then back to 2018 solved the issue for me in VS Code.