fix(macros): harden correctness pass authority boundaries#9
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a78879e345
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| let mut cursor = Some(path.as_path()); | ||
| while let Some(dir) = cursor { | ||
| if dir.join("Cargo.toml").is_file() { | ||
| return Some(dir.to_string_lossy().into_owned()); |
There was a problem hiding this comment.
crate_root_for_file() uses the first ancestor Cargo.toml as the isolation key, which collapses every target in one package (src, examples, tests, benches, extra bins) into the same bucket. When Cargo reuses the proc-macro process across those distinct crates, loaded_machine_is_current() / loaded_state_is_current() will treat metadata from another target as local, so duplicate crate::Machine or crate::State names can become ambiguous or resolve to the wrong item. That means the new code is isolating by package root, not by the “current crate” it claims to protect.
Useful? React with 👍 / 👎.
| fn loaded_machine_is_current(machine: &MachineInfo, current_crate_root: Option<&str>) -> bool { | ||
| if current_crate_root.is_some() && machine.crate_root.as_deref() != current_crate_root { | ||
| return false; |
There was a problem hiding this comment.
loaded_machine_is_current() only rejects foreign metadata when current_crate_root() returns Some(_). For include! fragments generated under OUT_DIR—a common way to produce transition impls—crate_root_for_file() finds no ancestor Cargo.toml, so this guard is skipped and lookup_unique_loaded_machine_by_name() falls back to every machine loaded in the proc-macro process. In builds that compile another crate with the same machine name, a valid generated include can now fail with the new ambiguous-machine path even though the conflict is outside the current crate.
Useful? React with 👍 / 👎.
1 participant
Summary
Verification