You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Rethink how we capture expectation conditions and their subexpressions.
This PR completely rewrites how we capture expectation conditions. For example, given the
following expectation:
```swift
```
We currently detect that there is a binary operation and emit code that calls the binary
operator as a closure and passes the left-hand value and right-hand value, then checks
that the result of the operation is `true`.
This is sufficient for simpler expressions like that one, but more complex ones (including
any that involve `try` or `await` keywords) cannot be expanded correctly. With this PR,
such expressions _can_ generally be expanded correctly.
The change involves rewriting the macro condition as a closure to which is passed a local,
mutable "context" value. Subexpressions of the condition expression are then rewritten by
walking the syntax tree of the expression (using typical swift-syntax API) and replacing
them with calls into the context value that pass in the value and related state.
If the expectation ultimately fails, the collected data is transformed into an instance of
the SPI type `Expression` that contains the source code of the expression and interesting
subexpressions as well as the runtime values of those subexpressions.
Nodes in the syntax tree are identified by a unique ID which is composed of the
swift-syntax ID for that node as well as all its parent nodes in a compact bitmask format.
These IDs can be transformed into graph/trie key paths when expression/subexpression
relationships need to be reconstructed on failure, meaning that a single rewritten node
doesn't otherwise need to know its "place" in the overall expression.
There remain a few caveats (that also generally affect the current implementation):
- Mutating member functions are syntactically indistinguishable from non-mutating ones and
miscompile when rewritten;
- Expressions involving move-only types are also indistinguishable, but need lifetime
management to be rewritten correctly; and
- Expressions where the `try` or `await` keyword is _outside_ the `#expect` macro cannot
be expanded correctly because the macro cannot see those keywords during expansion.
The first issue might be resolvable in the future using pointer tricks, although I don't
hold a lot of hope for it. The second issue is probably resolved by non-escaping types.
The third issue is an area of active exploration for us and the macros/swift-syntax team.
0 commit comments