[SR-7315] Decodable conformance of classes in different files yields bogus "Class ... has no initializers" error

[hamishknight]

Previous ID	SR-7315
Radar	rdar://problem/39102390
Original Reporter	@hamishknight
Type	Bug
Status	Closed
Resolution	Done

Environment

Swift version 4.2-dev (LLVM 95345677bd, Clang daefc772c1, Swift 76c264e)
Target: x86_64-apple-darwin17.4.0

Additional Detail from JIRA

Votes	18
Component/s	Compiler
Labels	Bug, Codable
Assignee	@slavapestov
Priority	Medium

md5: 041c433776ada41d9784d150b3a3cc07

Issue Description:

The following Swift files fail to compile:

class C1 : Decodable { // error: Class 'C1' has no initializers
  let str: String
}

class C : Decodable {
  let c1: C1
}

But they really should as we should be synthesising an init(from:) for C1. Note that the above example does compile with whole module optimisation enabled if the file a.swift comes before b.swift.

[hamishknight]

cc @itaiferber

[swift-ci]

Comment by Dave Poirier (JIRA)

Associated apple docs: https://developer.apple.com/documentation/foundation/archives_and_serialization/encoding_and_decoding_custom_types

All examples provided by Apple showcase the automatic compiler-generated initializers; there should not be any need to manually create the initializers if all properties are Codable/Decodable.

[belkadan]

@swift-ci create

[itaiferber]

Apologies for the delay in responding — I just got back from vacation. I can replicate this with Swift 4.1; C1 is not an issue on its own, but indeed, having C own an immutable C1 leads to this bogus diagnostic. Changing let c1: C1 to var c1: C1 allows compilation to succeed, while the following does not:

class C : Decodable {
    let c1: C1? = nil
}

Dropping Decodable conformance here fixes the issue:

class C {
    let c1: C1? = nil
}

Giving C1's str a default value also resolves the issue. This seems like a potential combination of multiple issues; C1 here gets a synthesized init(from🙂, but not a synthesized init() (because str doesn't have a default value). Something in C's Decodable conformance might somehow be requiring C.init(), leading to the error. The produced note ("Stored property 'str' without initial value prevents synthesized initializers") indicates an attempted synthesis of the default constructor, which fails; the question is why that might be necessary.

[itaiferber]

You'd get this same error, of course, if you dropped Decodable conformance from C1. It's possible that this doesn't directly have to do with the Decodable synthesis (which might be succeeding always), but actually with regular init() synthesis on C. The following rightfully complains that C has no initializers:

class C {
    let c1: C1
}

Synthesis of init() fails silently here (because c1 indeed has no default value). The presence of init(from🙂, however, might get us to not fail with "Class 'C' has no initializers", but fall over somewhere down the line instead (with this more confusing diagnostic).

In any case, I'll try to investigate this too with some of the other tasks that I have.

[slavapestov]

Shouldn't both C and C1 get an init(from🙂 synthesized? It looks like a bug in the type checker. I'm looking into it.

[itaiferber]

@slavapestov Yes, they should, and I think they do; I haven't had time to look into this, but if I had to guess, the diagnostic is being produced after Decodable synthesis here.

[slavapestov]

It looks like they're not being synthesized, which also explains the related bugs where vtable layout between translation units is inconsistent and causes runtime crashes.

[slavapestov]

I investigated this, same root cause as https://bugs.swift.org/browse/SR-6468.

[slavapestov]

#16050