RLS builds the 'debug' target instead of 'rls'

[patriksvensson]

I noticed that the Rust VS Code plugin suddenly was building using the debug target which gave a lot of conflicts when switching between VS Code and the command line and also led to a lot of non-incremental rebuilds for some reason.

By setting the rust.target configuration to rls I got it working again (see picture).

Not sure if I messed something up or if this is a regression in the plugin, so feel free to close this issue if you suspect the former.

Rust VS code version: 0.4.2
RLS version: rls-preview 0.126.0-stable (f5a0c91 2018-03-26)

[Xanewok]

Which RLS version are you using?

[patriksvensson]

@Xanewok

Rust VS code version: 0.4.2
RLS version: rls-preview 0.126.0-stable (f5a0c91 2018-03-26)

Updated the issue body as well with this information.

[Xanewok]

@patriksvensson that'd be on me - I introduced this bug and fixed it on Mar 29th (rust-lang/rls#793), so this should be fixed in newer versions =)

There is a single RLS version associated with a stable Rust release, so one workaround might be to set default "rust.target" to "rls" for now in the extension. @nrc what do you think?

[Xanewok]

@patriksvensson wait, setting rust.target fixed that? Shouldn't setting rust.target_dir be correct in this case?

[patriksvensson]

@Xanewok Correct, setting rust.target fixed that for me.

[Xanewok]

That's... unexpected! I'll look into that, thanks for reporting it.

[patriksvensson]

@Xanewok Hold on. I just verified and it creates the rls/debug folder but there's only a cargo.lock in there so it might not have solved it after all. Experienced no more problems after the fix though. Will try target_dir and report back.

[patriksvensson]

@Xanewok Setting rust.target_dir does nothing. I tried setting it to rls, but it still creates a debug folder. Tried setting the rust.target to rls as well, but that only creates the rls/debug folder with a cargo.lock file.

I deleted the target directory between changes and restarted VS code to make sure that nothing else was interfering with the results.

[zargony]

Same problem here (same versions: rls-vscode 0.4.2, Rust 1.26 stable, rls-preview 0.126.0-stable (f5a0c91 2018-03-26)). Setting rust.target_dir doesn't seem to have any effect.

As a workaround, it worked for me to set rust-client.channel to nightly (in my case that's Rust 1.27 nightly 2018-05-07, rls-preview 0.127.0-nightly (d2ade31 2018-05-08))

[AlexEne]

Just so I understand, the correct behavior is to have my_project/rls/debug and my_project/target/debug ?
Wouldn't target/rls have been a nicer option since that folder is already ignored by the default .gitignore ?

[Xanewok]

@AlexEne it definitely would have, it was mistake on my part. Merged fix in #316.

I'll close the issue, since this should be definitely resolved now.

⚠️ For anyone still encountering the issue, be sure to specify "rust.target_dir": "target/rls" in the User Settings for the time being, this should be resolved when a new version of the extension is published to the marketplace.

[scottjmaddox]

Setting target_dir is working as a workaround in one project, but not in another. It is working a project with a cargo workspace, though I'm not sure if that's the root cause of the difference.

Edit: It's not working in a brand new workspace project, though, so that's not the difference... I'll continue to investigate. Any tips on printing the version running inside VSCode, etc? A quick glance has not turned up any documentation.

Edit 2: well, running rls --cli from the command line inside the new test workspace shows the same problem (rls building into target/debug), so maybe it's not rls-vscodes fault after all? Just to be clear, the problem is in both non-workspaces and workspaces.

Edit 3: the issue definitely appears to be with rls itself; I've reopened my issue on the rls repository.