`Unresolved import` error highlighting when nothing is wrong

[tuvtran]

trafficstars

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

[tiagoamaro]

@tuvtran, I had this same issue with Rust 1.32.0. Upgraded to version 1.33.0 and RLS stopped reporting these false-negatives.

[colezlaw]

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.

[Xanewok]

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.

[Jayz33]

@tuvtran, changing the edition = "2018" to another (random) year and then back to 2018 solved the issue for me in VS Code.

[tqwewe]

@tuvtran I think you need to just change your VSCode theme, when you change everything should be much better.

[TobiasWehrum]

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.)

[Xanewok]

@TobiasWehrum Hit Ctrl+, and click the "{}" button to the right to open the settings.json, you should have some options changed there.

[TobiasWehrum]

@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"
}

[Xanewok]

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?

[TobiasWehrum]

cargo new t doesn't create a src/lib.rs for me, only a src/main.rs.

1. cargo new t
2. Open project folder in VS Studio Code.
3. Create and open src/lib.rs.
4. Add pub struct MyStruct {} to lib.rs.
5. Open src/main.rs.
6. At the beginning of the file, type use t::, don't get offered MyStruct by intellisense, remove the line again.
7. Add extern crate t;.
8. Type "use t::" below and this time get an intellisense offering to complete with MyStruct.

[Chris-Andrews]

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.

[fzxu]

exit vscode and re-open, fixed the issue.

[karipov]

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)

[axx]

@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.

[godcrying]

exit vscode and re-open, fixed the issue.

press <F1> and type Rust: Restart the RLS solved the issue for me.

[fodurrr]

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

[cryptoquick]

I also tried everything here and I'm still having this issue.

i use arch btw

[JeroMiya]

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?

[shapled]

I fix it with use crate::<my-mod>

[clifton]

same happens to me with rls nightly and rust 1.40. restarting VS code fixes it.

[sullivtr]

In VS Code I solve this issue by running the "reload window" command. Ctrl + shift + p then type "reload window"

[rebelC0der]

None of the previous solutions helped unfortunately.

• Latest VSCode
• Rust Beta (rustc 1.41.0-beta.1 (eb3f7c2d3 2019-12-17)) Same issue with other versions
• rls 1.41.0 (8f1c275 2019-12-10)
• Rust extension: Rust (rls)
• Script running extension: Code Runner

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:

1. The exact same issue is present in Atom editor.
2. Autocomplete almost does not work:

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.

[ChronosWS]

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.

[Zablas]

@RebelCoderRU I'm getting exactly the same errors as you.

[okke-formsma]

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)

[DongDuoFen]

I have the same "unresolved import"problem but autocompletion works fine,

[kaungst]

Seeing the errors as well, reloading the window fixed the issue for me

[CeleritasCelery]

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.

[ssokolow]

For the record, I just got the same problem (code compiles fine, RLS can't find dependencies) with this loadout:

• Kubuntu Linux 16.04.6 LTS

• VIM - Vi IMproved 8.2 (2019 Dec 12, compiled May 31 2020 11:42:24) Included patches: 1-856 (From this PPA)

• ALE (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:

1. cargo new whatever
2. cargo add actix (Note my distracted mistake here)
3. Open up Vim and copy-paste the first block of example code from the actix-web front page. (Leave Vim open from this point on)
4. cargo run
5. When it fails with errors about not being able to find actix-web and actix-rt, fix Cargo.toml
6. cargo run
7. If the bug reproduces, you should now be in a state where RLS is stuck pretending that actix-web and actix-rt were never added to Cargo.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.

[SeanChao]

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