A crash named EXC_BAD_ACCESS occurs with the following setup:
Swift 4.2.1 (as bundled with Xcode 10.1)
A protocol which is not class-bound, but which has a where clause requiring it to inherit from any other class
At least one function or variable requirement of that protocol
A class which conforms to the aforementioned protocol
A variable or constant whose type is explicitly the aforementioned protocol, and whose instance is of the aforementioned class
A call to the protocol-required function or variable of the aforementioned variable
Expected outcome
Calling the function or variable requirement on the implementation instance will actually call said function or variable
Actual outcome
Attempting to perform such a call results in EXC_BAD_ACCESS
Known workarounds
On the protocol, add : class to make it class-bound. This is not always possible as it results in a Swift compiler warning, and some projects/businesses require "Treat Warnings As Errors" be set to "Yes", which will cause this to fail a compile attempt
On the variable declaration, explicitly type it to the implementation class' type. This is not always possible as that type is not always knowable at that time of writing (e.g. implementation class might be internal to some other framework)
SSCCE
openclassBar {}
protocolFoowhereSelf : Bar { // Fix 1: change this to `protocol Foo : class where Self : Bar {`funcbar()
varbaz: Any { get }
}
classFooImpl : Bar, Foo {
funcbar() {
print("You called bar!")
}
letbaz: Any = "This is baz"
}
letmyFoo: Foo// Fix 2: change this to `let myFoo: FooImpl`myFoo = FooImpl()
myFoo.bar() // crash: EXC_BAD_ACCESS (code=EXC_I386_GPFLT)print(myFoo.baz) // if the previous line is commented-out, crash: EXC_BAD_ACCESS (code=1, address=0xfffffffffffffff8)
The text was updated successfully, but these errors were encountered:
Superclass constrained protocols (that is, protocol Foo where Self : Bar) aren't completely implemented in Swift 4.x, the syntax should have really been rejected. They are however implemented in Swift 5 – your code runs as expected when using Xcode 10.2 beta 2.
@hamishknight Fascinating! Unfortunately, due to company policy, I won't be able to test that since I'm not allowed to install Mojave. Will this fix possibly be patched into Swift 4.2 andor Xcode 10.1?
BenLeggiero (JIRA User) I don't believe so. You should however be able to use a Swift 5 snapshot toolchain with Xcode 10.1 (it may have to be a slightly earlier snapshot though to ensure compatibility with the old SDKs, 2019-01-23 works for me). That being said, I'm not sure if you're able to distribute iOS/macOS apps while using a development snapshot of Swift.
Dunno when this was fixed, but it seems to be working as of:
Xcode Version 11.1 (11A1027)
macOS 10.14.6 (18G95)
Apple Swift version 5.1 (swiftlang-1100.0.270.13 clang-1100.0.33.7)
Target: x86_64-apple-darwin18.7.0
Attachment: Download
Environment
Xcode 10.1 (10B61)
Swift 4.2.1
macOS 10.13.6 (17G5019)
Additional Detail from JIRA
md5: 6e55766998aa375ab1d917246fb28b04
Issue Description:
A crash named EXC_BAD_ACCESS occurs with the following setup:
Swift 4.2.1 (as bundled with Xcode 10.1)
A protocol which is not class-bound, but which has a
where
clause requiring it to inherit from any other classA class which conforms to the aforementioned protocol
A variable or constant whose type is explicitly the aforementioned protocol, and whose instance is of the aforementioned class
A call to the protocol-required function or variable of the aforementioned variable
Expected outcome
Calling the function or variable requirement on the implementation instance will actually call said function or variable
Actual outcome
Attempting to perform such a call results in EXC_BAD_ACCESS
Known workarounds
On the protocol, add
: class
to make it class-bound. This is not always possible as it results in a Swift compiler warning, and some projects/businesses require "Treat Warnings As Errors" be set to "Yes", which will cause this to fail a compile attemptOn the variable declaration, explicitly type it to the implementation class' type. This is not always possible as that type is not always knowable at that time of writing (e.g. implementation class might be
internal
to some other framework)SSCCE
The text was updated successfully, but these errors were encountered: