RLS folder *very* large

[Diggsey]

For a single project (stdweb) my target/rls/debug/incremental folder is 3 gigabytes. This is slightly ridiculous as the actual build folder is only 40 megabytes.

[alexheretic]

I think this could be related to an issue I've noticed with how cargo can only clean everything or nothing. As I update nightly each new toolchain build grows the ./target without cleaning the older, now incompatible, artifacts.

Do you have multiple copies of the same dependencies in your ./target/rls/debug/deps/ dir?

libserde-c16b0598a5624a93.rlib
libserde_derive_internals-203237d4f98c1e3e.rlib
libserde-91d14d384fd088f6.rlib
libserde_derive_internals-dd6dec978df7e0fe.rlib

In general this may mean multiple versions are required to build the crate, but otherwise they're leftover from previous build toolchains.

I raised rust-lang/cargo#5026 to ask about improving the situation.

In the meantime the only option is to remove the ./target/rls directory (or cargo clean) and restart Rls, letting it rebuild to the size required by a single toolchain.

[Diggsey]

No my deps folder is only 16mb.

My target\rls\debug\incremental\stdweb-1fr38zfxlj5fd on the other hand contains 130 subfolders of about 20mb each.

[alexheretic]

I guess it's a similar issue, if they are a range of different access times.

[nrc]

Hmm, it seems like the RLS is not doing some of the tidying up which either rustc or Cargo usually does for incremental compilation.

cc @michaelwoerister any idea what we're doing wrong here?

[michaelwoerister]

Maybe the RLS driver somehow skips the garbage collection step?

[nrc]

Should be fixed by rust-lang/rust#48181