Module execution 

What a run is allowed to run, and what it reads instead.

Semantic analysis wants things only a build can produce: a table a build script writes, the items a derive macro expands to, the flags a configure step decides. Producing them means running code out of the project being audited, which is the one thing a tool pointed at somebody else’s repository must not do by accident.

So execution is not a mode this tool has and can be talked into leaving. The default is that no class of execution is permitted, permission is granted a class at a time, and everything refused is reported: what was skipped, what it cost, and the exact thing to type to allow it. A skip nobody is told about reads as an answer.

Why per class

One switch for “run things” collapses decisions of very different weight. Expanding a procedural macro runs a compiler plugin the project already trusts its own developers with; running a configure step runs a shell script that may reach the network. Somebody willing to do the first is not thereby willing to do the second, and a single flag would make agreeing to either mean agreeing to both.

What is always allowed

Reading what the project already has: manifests, a compilation database, artifacts a build left behind, debug information. None of them run anything, and they are listed explicitly (Reading) rather than left as “whatever is not execution”, so that a new information source has to be classified before it can be used.

Structs

ExecutionPolicy

What a run is permitted to run.

Limits

The ceilings a run works under.

Refusal

Why something was not done, and how to change that.

UnknownExecution

A permission naming a class that does not exist.

Enums

Execution

Something that would run code supplied by the project being audited.

Reading

Something a run may read without running anything.

Constants

EXECUTION_CLASSES

Every class, in a fixed order.