[NFC] A Handful of Sweeping Evaluator Cleanups #30669
Conversation
|
@swift-ci test |
|
@swift-ci test |
1 similar comment
|
@swift-ci test |
|
@swift-ci test Windows |
|
Build failed |
|
Build failed |
|
@swift-ci please smoke test |
1 similar comment
|
@swift-ci please smoke test |
|
@swift-ci please smoke test |
1 similar comment
|
@swift-ci please smoke test |
Introduce evaluator::SideEffect, the type of a request that performs some operation solely to execute its side effects. Thankfully, there are precious few requests that need to use this type in practice, but it's good to call them out explicitly so we can get around to making them behave much more functionally in the future.
|
Due to the incredible subtleties of C++, this was actually quite the behavior change. I accidentally list-initialized the Optional part of |
A request is intended to be a pure function of its inputs. That function could, in theory, fail. In practice, there were basically no requests taking advantage of this ability - the few that were using it to explicitly detect cycles can just return reasonable defaults instead of forwarding the error on up the stack. This is because cycles are checked by *the Evaluator*, and are unwound by the Evaluator. Therefore, restore the idea that the evaluate functions are themselves pure, but keep the idea that *evaluation* of those requests may fail. This model enables the best of both worlds: we not only keep the evaluator flexible enough to handle future use cases like cancellation and diagnostic invalidation, but also request-based dependencies using the values computed at the evaluation points. These aforementioned use cases would use the llvm::Expected interface and the regular evaluation-point interface respectively.
|
@swift-ci please smoke test |
1 similar comment
|
@swift-ci please smoke test |
|
@swift-ci test |
|
Build failed |
|
Build failed |
|
⛵️ |
These commits contain:
evaluator::SideEffectreturn type - an alias tostd::tuple<>llvm::Expected. Request evaluation itself may still fail with an error - that is a valuable behavior to preserve because it means we can still perform rich error reporting and handling during request evaluation. But the evaluation functions themselves have no need to return error values as they should be pure functions of their input state. The evaluator framework itself handles the actual cycle detection and request cancellation portions just fine.A few requests that were taking advantage of being able to cancel cycles by bubbling errors back up were reverted to their behavior before #18454.