rerere is a lifesaver here.

(I’m also a fan of rebasing; but I also like to land commits that perform a logical and separable chunk of work, because I like history to have decent narrative flow.)

Given the widespread existence of wasm sandboxing, rustc itself might want to think about alternative strategies for running compiler plugins. I suspect there’d be a performance hit with such an approach, but wasm tooling is getting really good; perhaps it is minor.

Apology appreciated, but unnecessary.

I don’t want to derail a useful tool. It’s worth going a bit beyond “hope” as a strategy, however, and thinking about if (how) this might be exploited.

I doubt anyone will be mining crypto in your sandbox. But perhaps you should think about detection; might it be possible to mask a malicious crate with a second that attempts to detect sandboxed compilation, for instance?

In any case, I think this still looks exceedingly interesting in the typical case, which is of detecting the impact of bugs from non-malicious actors.

Given the existence of macros, doesn’t this let package maintainers run arbitrary code in the painter sandbox?

Yes. The sandbox gets whatever capabilities you expose to it.

I had a small X.25 network as combination coffee-table and space-heater at one point; this was before most homes had internet. It almost cost me a divorce.

Doesn’t need to be a “traditional” container. Modulo noisy-neighbour issues, wasm sandboxing could potentially offer an order of magnitude better density (depending on what you’re running; this might be more suited to specific tasks than providing a substrate for a general-purpose conpute service).

That’s not correct, but it shouldn’t preclude you from applying defence in depth.