Can rustc/cargo benefit from Unison's cache/hash idea?

Unison intro: https://www.youtube.com/watch?v=IvENPX0MAZ4

I understand that cargo has incremental builds. However, often times, it feels like cargo is re-parsing and re-type checking my entire code base.

Unison has this idea of 'hashing' code by content. As a result, a particular piece of code is only parsed / type-checked once (and then cached).

I'm wondering if this idea can be extended to cargo/Rust.

  1. I understand this will have complications with macros.

  2. Is it possible for this to work with generics? (Seems like the use of generics will either (1) results in lots of re-computation or (2) a large cache of every type we ever instantiated a function with.)

===

Having a < 0.1 sec "cargo check", regardless of codebase size, would be insane. [In theory, this seems possible since in a 'unison' style world, we should only need to parse / type checked the "diff" rather than the entire code base.]

1 Like

Note that I did not watch the video (I could have read a text, but a 30mn video is too long).

In C++, build2 hash the source file, after pre-processor expansion, and whitespace stripping, and store the hash with the result of the compilation. When doing a rebuild, he re-do the first step of running the pre-processor + whitespace stripping, but doesn't need to compile the file if the hash already exists in its cache.

I assume a similar technique could be used in rust. C++ macro are not hygienic (the order or includes may matters), but I don't think it's the case in rust. So maybe it could be done even earlier (like just stripping whitespace in a source file + computing its dependencies).

Rust is already working on incremental compilation, which is basically this except it correctly handles stuff like generics, and other cases where changes in one file can make another file fail to compile.

2 Likes

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.