mirror of
https://github.com/apple/swift.git
synced 2025-12-14 20:36:38 +01:00
20ff4dfc57
That does not work if there is a resilient class in the hiearchy from a different module than the testable imported one. Rather treat an internal but testable imported class as having resilient metadata. The scenario that does not work assuming we can build a fragile layout is the following. FrameworkA is resilient and defines a public class `Base` with a stored field. FrameworkB is resilient and defines an internal class `Sub` that inherits from the class `Base` in FrameworkA and adds some fields. FrameworkB is compiled with enable-testing. The test case testable imports FrameworkB and accesses a field in the internal class `Base` from FrameworkB. The test case only has access to FrameworkA's public swiftinterface file and therefore does not know `Base`'s layout. The layout computation for `Sub` cannot take the field from `Base` into account and things fail silently. rdar://103323275
15 lines
187 B
Swift
15 lines
187 B
Swift
import FrameworkA
|
|
|
|
final class SubThing: BaseThing {
|
|
var y = 2
|
|
var z = 3
|
|
|
|
override init() {}
|
|
|
|
func printThis() {
|
|
print("x \(x)")
|
|
print("y \(y)")
|
|
print("z \(z)")
|
|
}
|
|
}
|