I’ve seen this loosely tossed around but I haven’t seen any concrete discussion (maybe I missed it). We can now load macros and lints from external crates, so we can theoretically have none of these hardcoded into the compiler.
expand) to librustc_macros
- have the compiler insert
#[phase(plugin)] extern crate librustc_lints; #[phase(plugin)] extern crate librustc_macros;at the same time as it inserts
extern crate std
- possibly provide a way to opt-out, although there is currently no way to opt-out, and this change would not impose any additional runtime dependencies on the generated executables. In any case, it’s very desirable to have lints in
#[no_std]code so if an opt-out is provided, it should not be reusing the
This should just be an internal change which is not meaningfully user-visible. The benefits include faster iteration times, since these crates depend on libsyntax/librustc (resp.) but not vice versa, so changes to macros and lints do not need to spend time doing the slowest part of the bootstrap (that is,
make after a change to a lint will just need to build stage0 rustc_lints and then immediately start on the stage1 libraries).
Unfortunately, this may have staging issues, and possibly even problems with (soon to be removed) rpaths, due to the dynamically loading.