Incremental builds occupy a lot of space. (19GB for a small sized project)

[AlexEne]

I originally posted this on the RLS bug tracker ( rust-lang/rls#709 ) and it was suggested to open an issue here.

These builds in the RLS subfolder generate a lot of files that eat up a high amount of disk space for the project I am working on. (19 GB)
All this in target/rls/debug/incremental/

For a project that's about a few thousand lines of code, it uses around 16GB of disk space. Now I am unsure of what generates this, I use RLS as part of visual studio code.
All the files are generated while I worked on my project today: (11 Feb 2018). Or they were at least modified today.

For reference this is the lines of code output for my project (not too big).

If you want to reproduce the issue, I can give you access to my repo, or we can work something out.

[sfackler]

cc @michaelwoerister

[michaelwoerister]

For some reason session directory garbage collection seems to be broken here. There should only ever be a couple of those directories starting with s-.

As a quick workaround, you can just delete all of these directories while no rustc instance is running.

Has anybody observed this on platforms other than Windows?

[michaelwoerister]

@nrc, will a rustc invocation done by the RLS ever hit this line:

rust/src/librustc_trans/lib.rs

Line 263 in 4d2d3fc

rustc_incremental::finalize_session_directory(sess, trans.link.crate_hash);

This call seems to in the wrong place anyway, since it is not trans-backend specific. I'll look into moving that to the correct spot.

[AlexEne]

Thanks for the help.

[kjeremy]

@michaelwoerister yes I see this on Ubuntu 16.04

[nrc]

@michaelwoerister we skip trans completely, so I would expect that it won't hit that. I have not verified though.

[michaelwoerister]

@nrc, I've taken a look yesterday and --emit metadata should also go through LLVM trans, so the RLS should hit the finalization if it compiles everything successfully. When there are errors, it may exit early though. #48181 makes sure that we don't rely on successful builds for running the garbage collection. Let's see if that solves the problem.