[WIP] Allow annotating proc macros to live in the exec universe for feature resolution

[dzbarsky]

No description provided.

[stepango-xai]

Got my agent to run some tests on #157 vs #168 here is the verdict :)

Performance (448-core box, cold bazel clean, no disk cache)

Metric	base v0.0.93	PR 157	PR 168
Cold build wall	221.7 s	223.0 s	221.2 s
Executed Rustc actions	330	328	333
Crate libs compiled in >1 variant	11	8	11
Total Rustc CPU	401 s	416 s	447 s (dup syn_exec/syn_target = 28 s)
Crate-resolution re-eval	~23 s	~23 s	~26–38 s (+15%+, full second pass)

• PR 157 resolves two worlds (cargo resolver-v2 semantics). Host world genuinely re-resolves: hyper-rustls_host got ["http1","http2",…,"ring",…] — aws-lc-rs and default dropped, ring substituted, exactly the PR's promise. Only 22 _host siblings appeared in this target's graph (lazy, divergence-only). Side effect observed: openssl-sys_host entered the exec cone (host-world native-tls resolves differently) — new work that baseline didn't have.
• PR 168 resolves target world with build-deps/proc-macro edges deferred, then seeds an exec world. But exec features are seeded from target-world activations, so exec rustls_exec still carries aws-lc-rs (only lost default/prefer-post-quantum). It rendered 150/269 fetched spokes with _exec splits — mostly spurious feature-subset diffs (syn, quote, proc-macro2…), each becoming a duplicate compile. Selection happens at build time via the fork's rules_rust_use_exec_features transition flag rather than statically in dep labels. It's also [WIP], no description, and proc-macro world-crossing is opt-in via crate.annotation(is_proc_macro = True) per crate — for us that'd mean annotating every proc-macro in a 4k-crate lock to get the full benefit.

[dzbarsky]

Thanks for trying it! "exec features are seeded from target-world activations" sounds off to me, that might be a bug. Some of the other things in the table above also seem surprising to me; let me give this a spin on openAIs repo when I'm back at work next week