CaptureRefusals::is_empty and CatchUpBlockers::is_empty take their struct apart whole, as pending_work does, where each read its fields one by one, so a field added to either struct fails to compile in is_empty as it does in pending_work, where is_empty compiled over it and primary_state would have read a primary holding only that cause as clean. a note where each struct is defined says a reader that decides emptiness or wording from its fields takes it apart whole, and CONTEXT.md says so. no behaviour change. shown with a throwaway field on both structs, then removed: with the old bodies loot-core and loot-cli compiled and only pending_work failed (E0027 at both of its patterns), and with the new ones is_empty failed in each crate (E0027 in engine.rs and reports.rs). cargo test green, 4970 passed over 144 test result lines with 15 ignored. owes no deploy (xxlvlknm) 3abee499 · dbf3dbe6…
Renames are not followed. loot's tree maps a path to an address, so a rename is a delete and an add. This list is the history of the name, not of the bytes.
