Making the compiler interface on-demand driven

[Zoxc]

@nikomatsakis

This isn’t quite the interface that I had imagined, but then I’m not entirely sure what I was imagining anyway. I’ll have to browse your PR to help form my opinion.

I'd think of this as a temporary interface until we get end-to-end incremental queries. It should probably be revisited then.

@nikomatsakis

Are we able to implement this interface without unsafe code (especially the points regarding internal references)?

No. However, this would be possible to do if we had generators with arguments. Currently my branch uses a safe abstraction using macros. It would be a bit cleaner to just yield raw pointers here. I structured the code the way I'd write it in safe code given generator arguments.

@nikomatsakis

One could also imagine passing in the arena as an argument when creating the Compiler , and having the Compiler interface be parameterized by a lifetime ( 'gcx , basically).

We want to destroy the arenas while we have a Compiler type around. The resolver has it's owner arena (in BoxedResolver) that is freed and BoxedGlobalCtxt is freed in the compile method to minimize memory usage.

@nikomatsakis

I was also a bit surprised to see that the “stealing” concept is so central in this interface. Perhaps that makes sense given how the code works.

We want to avoid cloning large structures like the AST, HIR, etc. It also allows code to easily free results of queries by just stealing them.