Skip to content

Conversation

@keithw
Copy link
Contributor

@keithw keithw commented Jan 28, 2026

This PR adds an atomic feature to the validator, exposing a FuncValidator::atomic_op function that tries to validate an operator and leaves the validator unchanged if the operator is invalid.

The feature adds a "rollback log" to the OperatorValidator; the log keeps track of any information destroyed during validation of the operator, so that the validator can be rolled back to its initial state if the operator turns out to be invalid. I tried to make this basically performance-neutral for anybody who doesn't need this. The rollback log is only present if the atomic feature is enabled, and it's only used if atomic_op is being used (i.e. the visit functions and FuncValidator::op don't use it).

We're using this as part of a Wasm development/teaching environment where we'd like the validator to be in a predictable state after an invalid operator.

FuncValidator::atomic_op validates an operator, leaving
the validator unchanged if the operator is invalid.
@keithw keithw requested a review from a team as a code owner January 28, 2026 18:44
@keithw keithw requested review from dicej and removed request for a team January 28, 2026 18:44
@alexcrichton
Copy link
Member

If performance is ok to compromise on a bit here, the Clone-ability of a FunctionValidator might be sufficient here because the validator could be cloned before the operation and then thrown away if validation succeeded. That'd likely have some quadratic performance in terms of stack depth, however, so I can see how that wouldn't be desirable for handling large functions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants