How do we feel about a #[native_rule] proc macro? I want one because I want to port rule code to rust, and I think rust ports sharing shape with python rules is powerful. I also want one to make the instrinsic-to-intrinsic have 0 python frames and largely be about IO and that opimization space, instead of the weird place it is in now where python runtime is non-zero even when intrinsic rules call each other. I did this in a bit of a exploratory hacking to find the right shape trying to make

find_ancestor_files

(a very python hot rule in my work repo) portable without (what I hope) impact on readability. Design choices are: implicitly-discovery being included in the proc-macro to mirror python. Not as powerful as the python ast parser, but maybe good enough for native rules? https://github.com/pantsbuild/pants/blob/5ed90d488a23da2423ab55d7984e72e79b0f0ecb/src/rust/engine/src/native_rules_builtins.rs#L109 This work depends on my currently open PR:s.

I definitely enjoy Rust more than Python at this point

Naive questions: Would this allow a ported rule to re-use the existing python tests with no changes to said tests? (Or is that already the case?)

rule-runner based aye

Not sure how much you're using LLMs for this work, but from my past couple of months experimenting with Claude in the pants repo, which has been a mixed bag, I have a sense that it might be relatively helpful in this kind of work.

Are the series of ports a pre-req for a rule macro, because all rules happen to use those classes? Or a different reason?

Yes, sort of. Any type you want to "name" in rust has to be a pyo3 struct for it to be ergonomic to use. Writing native rules is way too verbose without it, and these base types (e.g Target, SourceField) are ubiquitous