# Moving bits of rustc into crates

**URL:** <https://internals.rust-lang.org/t/moving-bits-of-rustc-into-crates/7607>\
**Category:** compiler\
**Created:** [May 21, 2018, 6:54pm UTC](https://internals.rust-lang.org/t/moving-bits-of-rustc-into-crates/7607 "2018-05-21T18:54:18Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![cuviper](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/cuviper/32/1897_2.png) [@cuviper](https://internals.rust-lang.org/u/cuviper)\
**Post date:** [May 21, 2018, 7:56pm UTC](https://internals.rust-lang.org/t/moving-bits-of-rustc-into-crates/7607/4 "2018-05-21T19:56:04Z")

</div>

> [@nikomatsakis](#):
>
> It’s harder to land an “atomic change” that affects many things.

Externing anything using unstable features will make it especially annoying to change those features. If nothing else, the current `cfg(stage0)` hacks would have to get even more hackish. Being nightly-only will also limit the chances of such crates building up their own community.

For those crates that can work with the stable language, it seems less of a problem.

Your prior post is also relevant to remember:

> [@Rustc dependency policy](https://internals.rust-lang.org/t/rustc-dependency-policy/6537):
>
> So, thanks to all the hard work on ./x.py, we have the ability to pull in crates from [crates.io](http://crates.io) and elsewhere. This is wonderful. However, we currently impose some pretty minimal requirements on said crates. As far as I know, we just check that they have suitable licenses. Recently, rayon encountered some problems due to its use of compiletest-rs, which turns out to be depending (on windows) on the dbghelp library. This is because of miri which uses backtrace. This strikes me as a kind of warn…

---

_[View the full topic](https://internals.rust-lang.org/t/moving-bits-of-rustc-into-crates/7607)._