rustc_driver is essentially
main() function. It acts as
the glue for running the various phases of the compiler in the correct order,
using the interface defined in the
rustc_interface crate provides external users with an (unstable) API
for running code at particular times during the compilation process, allowing
third parties to effectively use
rustc's internals as a library for
analysing a crate or emulating the compiler in-process (e.g. the RLS or rustdoc).
For those using
rustc as a library, the
function is the main entrypoint to the compiler. It takes a configuration for the compiler
and a closure that takes a
run_compiler creates a
Compiler from the
configuration and passes it to the closure. Inside the closure, you can use the
to drive queries to compile a crate and get the results. This is what the
rustc_driver does too.
You can see a minimal example of how to use
You can see what queries are currently available through the rustdocs for
You can see an example of how to use them by looking at the
rustc_driver::run_compiler function (not to be confused with
takes a bunch of command-line args and some other configurations and
drives the compilation to completion.
rustc_driver::run_compiler also takes a
Callbacks. In the past, when
rustc_driver::run_compiler was the primary way to use the compiler as a
library, these callbacks were used to have some custom code run after different
phases of the compilation. If you read Appendix A, you may notice the use of the
CompileController, which no longer exist.
replaces this functionality.
Warning: By its very nature, the internal compiler APIs are always going to be unstable. That said, we do try not to break things unnecessarily.