swiftlang
Property accesses in failed expectations sometimes include their value twice in expanded description
This fixes a bug in which some property access expressions passed to #expect or other expectations will include their value twice, redundantly, in the expanded description if they fail.
Here are two examples showing the expanded description before and after this fix:
// BEFORE: ❌ Expectation failed: !([].isEmpty → true → true)
// AFTER: ❌ Expectation failed: !([].isEmpty → true)
#expect(![].isEmpty)
struct Outer {
struct Middle {
struct Inner {
var value: Int? = nil
}
var inner = Inner()
}
var middle = Middle()
}
let outer = Outer()
// BEFORE: ❌ Expectation failed: (outer.middle.inner → Inner(value: nil)).value → nil → nil
// AFTER: ❌ Expectation failed: (outer.middle.inner → Inner(value: nil)).value → nil
_ = try #require(outer.middle.inner.value)
The problem is that the keyPath associated value of the __Expression.Kind.propertyAccess enum case is an __Expression and recursively expanding it includes its runtime value. However, the overall property access is an expression too, and when it gets expanded, it includes that same value. So storing keyPath as an expression and expanding it is redundant. The source code of keyPath needs to be stored, but it doesn't need to be an __Expression.
Conceptually, property accesses should be modeled more like function calls: the result of a function call expression is not stored as associated value of the functionCall enum case.
Modifications:
- Change the
keyPathassociated value of__Expression.Kind.propertyAccessto be aStringcontaining the name of the property, rather than an__Expression. - Update the logic for recursively expanding a failure description for a faled expectation as a result of the previous change.
- Change the implementation of
#expectand similar macros to emit the property name as a string literal rather than an__Expressionfactory function. - Add new tests.
Result:
The two examples given above no longer include the property value twice.
Checklist:
- [x] Code and documentation should follow the style of the Style Guide.
- [x] If public symbols are renamed or modified, DocC references should be updated.
