PropertyWrapper + Codable = Segfault?

Using Swift
,
1

We're using a propertywrapper in a Codable struct. Everything works fine, except when we do a full clean build: the compiler segfaults always in that case.

(The propertywrapper itself is also conforming to Codable)

Is this a supported configuration or are we hitting another swift crash?

struct Message: Codable {
	@ServerTimestamp var time: Date?
	var text: String?
}
2

In general, Codable synthesizer works with property wrappers. It'll use ServerTimestamp implementation with the key time. So maybe there's something in the ServerTimestap.decode/encode that crashes the compiler. If that'd help with figuring something out.

3

Regardless of whether it's valid code, the compiler should never crash. If you have a reduced test case, a bug report on bugs.swift.org would be appreciated.

1 Like
4

We have multiple swift toolchain segfaults a day in our swift project: writing up bug reports that go into Apple's black bug reporting hole is not something we can afford.

We usually just workaround the segfaults by reordering code or figuring out if something is not supported at all and then stop using that feature. That's why my question is if this is supported officially :slight_smile:

5

Swift’s bug reporter is much less of a black hole, so I find it far more worthwhile. It is public though, so you may have more restrictions attaching code.

In any event, the point stands: the compiler should never crash, regardless of whether some syntax is supported.

1 Like
6

The compiler should either compiler your code (hopefully correctly), or report that something is wrong with it (like using unsupported feature). It simply should never crash. If you can isolate the problem that crashes it, all the better.

1 Like
7

In an ideal world it should never crash, indeed. Swift's toolchain is far from stable unfortunately and a bunch of features don't seem to be officially supported (generics + extensions + objc has never worked well for example) and have crashed the compiler for years. We try to avoid those features now.

8

All the more reason that it should be reported. If no one is saying anything, no one will be fixing anything. Though, it's understandable that figuring out the proper and small combination that causes the problem, then reporting it, does take some work, with no apparent result.

Anyhow I can attest that people do read the Swift bug reports.

1 Like
9

Please file a bug at bugs.swift.org with a self-contained reproducer. I would also recommend trying the latest version of Xcode (including beta) to check if the crash has been fixed.

1 Like
10

Back to the original question. Yes, such usage is supported. Many codable libraries have been using this structure for a while now.

11

Thanks, that's all I needed to know! Time to find a workaround. Perhaps not relying on Codable synthesising does the trick.

12

What does ServerTimestamp look like? It should most definitely work if it's synthesised all the way through. Even the custom decode shouldn't make much different.

13

ServerTimestamp comes from Firestore, a 3rd party Google framework: firebase-ios-sdk/ServerTimestamp.swift at 24e23931b43c7791b456d92eede67ebd88ae525d · firebase/firebase-ios-sdk · GitHub

  • We tried copying the definition to be in the same file, but it results in the same segfault, so the issue is not that the wrapper is defined in another file
  • We tried compiling with different optimization levels
  • Our next try will be to implement Codable ourself on this struct rather than relying on the compiler synthesizing it for us.
14

Hmm, I tried to copy out ServerTimestampWrappable into a new file (with Timestamp replaced with Double). It works & encode/decode w/o any problem. Hope that helps.