Using rustc internal API makes a lot of things easier, as it provides features such as type resolution, world-class macro expansion, and so on.
I wrote a very simple proof-of-concept which shows that it is possible to extract the public API from a crate here.
IMO cargo-breaking would benefit from it since we wouldn't have to reimplement some parts of the compiler ourselves. For instance, the current path resolution algorithm works only on very simple situations, does not handle glob imports, dependencies, and so on. If we switch to rustc API, this kind of problem vanishes. We could reinvest the time we currently spend trying to understand and mimic the compiler internal algorithm in actually valuable development.
However, this approach comes with some drawbacks:
launching correctly the compiler is a bit tricky, especially when dependencies are involved (spoiler: they always are in this context),
the compiler architecture itself is very complex, even more complex than syn's lossless AST,
we will have to generate a glue crate on the fly, which will complicate the way we write tests a bit. The best solution could be to write a replacement for the current parse_quote, that handles temporary crates generation (maybe tempfile can be used here).
Development will happen on the rustc-backend branch.
Using rustc internal API makes a lot of things easier, as it provides features such as type resolution, world-class macro expansion, and so on.
I wrote a very simple proof-of-concept which shows that it is possible to extract the public API from a crate here.
IMO cargo-breaking would benefit from it since we wouldn't have to reimplement some parts of the compiler ourselves. For instance, the current path resolution algorithm works only on very simple situations, does not handle glob imports, dependencies, and so on. If we switch to rustc API, this kind of problem vanishes. We could reinvest the time we currently spend trying to understand and mimic the compiler internal algorithm in actually valuable development.
However, this approach comes with some drawbacks:
syn's lossless AST,parse_quote, that handles temporary crates generation (maybetempfilecan be used here).Development will happen on the
rustc-backendbranch.