[CFG] rust.target_dir is broken

[boozook]

The last release (0.4.2).

Default value for rust.target_dir is "rls", so the result dir-tree looks like this:

project_root/
    rls/
    src/
    target/

If I set "rust.target_dir": null or "rust.target_dir": "target/rls" - all is ok, old behaviour is restored.
I think we should fix it and mb. change default value.

[boozook]

Oh, I think it was fixed in 0.4.4.

[scottwillmoore]

I believe I am also experiencing the same issue. I also don't believe it has been fixed, as I am using 0.4.4.

From what I can see, it appears that rls-vscode extension is not respecting the user setting: rust.target_dir: "target/rls". When deleting my target directory and then restarting vscode only the target/{debug,doc} directories are created, regardless of the value that rust.target_dir is set to. By default it is set to target/rls and I did originally have a target/rls directory, before I deleted it.

Using process explorer I can see that the rls.exe has a handle to one of the DLLs in the target/debug directory. This rls.exe is a sub-process of code.exe. I can build and run my Rust code perfectly fine without vscode opened.

I am current using a Windows host with the stable channel of Rust installed through rustup. I use the user setting: rust-client.channel: "stable".

I am more than happy to gather more information if that is needed.

[scottwillmoore]

After some experimenting, I have found that setting rust.target: "rls" (not rust.target_dir!) will make rls use the target/rls directory. I just saw the option in the user settings and thought I would try it and it worked?! I am not sure what the correct option is too use, but at least for now this allows me to edit with rls and compile and run at the same time.

[Xanewok]

Fixed as of 0.6.1.