That resource tells us what the code people use looks like, but it doesn't tell us how rustc behaves with it. Crater lets us tell if we've introduced a regression on features people use, but it doesn't tell us for example that compiling tokio got slower or faster, or that there's a high prevalence of code with large types, so we should focus on optimizing those. It also doesn't tell us how rustc behaves on code that is being modified, which will be incomplete/broken/weird. That kind of code is never committed to a repo.

> It also doesn't tell us how rustc behaves on code that is being modified, which will be incomplete/broken/weird.

Hmmm, good point. It also wouldn't tell you what someone did before giving up because they would never commit code.

Still, it's a useful data point. You could, say, time the build for the top 100 crates once a week, or gather metrics on language features that they use.