The inspiration for this in my mind is Windows' Static Driver Verifier, which probably does more now, but circa 2008 at least it knew the state machine required for correct driver behavior, and would ensure that your callbacks called some next thing correctly, released resources when required, etc.

I think this is necessarily a boutique tool.* It's a static analysis pass that understands the semantics of the expected execution flow of Tock. It assigns meaning to set_client based solely on our assertion that a function so-named is special. It understands what a Client HIL (trait matching [:alpha:]+Client) expects. Etc. I imagine it can enforce rules such as

• Track downcall/upcall path to make sure DeferredCall or similar mechanisms are used where needed
• finalize in components must call set_client OR (XOR?) setup (from here)
• Enforce many of the guidelines in TRD3

If anyone happens to teach a compilers class, or has a colleague looking for projects, this could be a reasonable class 'add-a-pass' project, especially for the simpler rules.

Mechanistically, it probably lives as a CI pass in our (github) cloud — can't imagine downstream folks want a hand-rolled compiler pass in their release stream, nor should we ask most developers to figure out how to compile and inject passes in (! nightly) llvm/cargo, etc. But all that is a bit cart ahead of horse.

*Though, maybe there is a research project somewhere to see if there is some ergonomic way to use the type system to pass in objects that you have to give to other callbacks etc to satisfy state machine requirements. Off the cuff, I think that it would be too kludgy to pull that off—it would look like capability passing on steroids—but maybe I'm wrong and there's some interesting trick.