mark-simulacrum

Thanks for pointing this out! Unfortunately, unlike most of our docs we don't yet have testing in place for the code examples on the blog. I've just pushed up a fix though so once that propagates this should be fixed.

We're going to publish that soon -- it needs to be generated after the release is tagged and it took longer today. We'll edit the blog post when it's ready to go.

For the initial release, NLL will be enabled in "migration" mode in 2018 only. `#![feature(nll)]` will continue to be available -- that hard-enables MIR borrowck instead of the migration mode. (edit: to be clear, the feature gate is not stabilized, but it will be available on nightly)

Migration mode means that the MIR borrow check will run, and if it errors, then AST borrow check will run, and if that compiles successfully then the MIR borrow check errors will be downgraded to warnings. If MIR borrow check is successful then AST borrow check does not run and its errors will not impact the results.

Eventually we will enable MIR borrowck fully on all editions; I personally hope this happens sooner rather than later so we can delete the old code, but we have no concrete timeline just yet.

The future use for this will be to allow calling methods/functions/macros from 2015 edition code in 2018, where some additional keywords have been reserved.

For example if you are using a crate with "dyn" as a method name then from 2015 you can call it via some_crate::dyn() but in 2018 you couldn't, since it's a keyword, but you could use some_crate::r#dyn(). That's the primary intent for this addition, though I believe some other use cases might be available as well.

Depending on what you're doing, there's often a few different approaches to reducing compile times. First of all, if you're going to be running (small) tests, then it may be beneficial to enable incremental with `--incremental` or `-i` to x.py. This does make the resulting compiler slower, but does make the build itself faster.

If you're making type-level changes that aren't going to alter functionality, or want to just make sure the whole compiler will build, you can run `x.py check -i` to get the equivalent of `cargo check` outside of the compiler tree.

If you know ahead of time that you're not changing the code generation/ABI of the compiler (metadata, mangling, that sort of thing) then you can also do something like `x.py --keep-stage 0` and work entirely in stage 2 (you wouldn't pass --stage 1 with this option). Alternatively, you can pass `--keep-stage 1` and run the stage 1 tests; this will save you a rebuild of std and test which is often unnecessary after a compiler change.

However, even with these suggestions/hints, building the Rust compiler can be rather slow.