Cache compilations of everything from crates.io

[prasannavl]

A simple way to resolve, both simple local compilations, and large scale compilations. It's such a pain today, and wasteful to have to recompile every single cargo dep into every single new project. It's also awful that RLS has to do it for analysis as well.

Use the semantics that cargo already uses to resolve crates (versions, git, etc), and create a directory tree under a common cache location - say $HOME/.cargo/cache/crates.io/, with all variable attributes: {target-tuple}/{name}/{version}/{feature-set}.{0}, etc, and leave the non-binary compilations there. So, it should likely speed up compile time in 90% of the general cases.

How to handle variable flags, like optimzation level, etc?

Drop a {version}/flags file in the tree that's a map of the flags to the {0}. This {0} can be expanded to anything, quite simply just an integer, or datetime.

This process can further be optimized later, on which compile flags need a separate tree, using the same flags mapped tree model above. For a quick start, anything that has different flags can be recompiled into a separate one just to be safe.

Other stuff

• Provide a clean-cut isolation for projects that require it. A simple flag both in command line and Cargo.toml that bypasses all the cache, and behaves the way it does today.
• Add a clear-cache command or something similar that clears the compilation cache to cargo.
• Later expand the clear-cache or provide additional commands that remove items in a smarter fashion to ensure stale caches aren't wasting space.
• Let RLS use this cache for analysis when appropriate.

[alexcrichton]

You might be interested in trying sccache which I believe solves many of these concerns?

[epage]

This appears to be the same as #5931, closing in favor of that