That's a new one. Is there any more information you can share? Anything from the "stack dump" section, or perhaps the definition of the problematic subclass initializer?

@swift-ci create

Comment by Amro Mousa (JIRA)

Here's an example of a problematic initializer definition:

​class SingleAutoplayableManagerDebugView: UIView {
    init() {
        super.init(frame: .zero)
    }
    ...
}

Some cases, like this one, are just this simple (really don't need to be there are all...). However, in other cases the initializers initialize subviews or other instance variables as well.

I can't say I'm familiar with the parts of our codebase triggering this.

Give me a bit to repro and get the full error text for you.

Comment by Amro Mousa (JIRA)

Full error message text attached as requested

error.txt

While deserializing SIL function "$S9T1Twitter16MomentFollowViewCACycfC"

$S9T1Twitter16MomentFollowViewCACycfC ---> T1Twitter.MomentFollowView.__allocating_init() -> T1Twitter.MomentFollowView

Hm. Since we have a specific example here, can you confirm that MomentFollowView directly subclasses UIView, and therefore shouldn't be referencing init()?

Comment by Amro Mousa (JIRA)

Yes, that view subclassed UIView directly.

Showing my ignorance here: Is init() marked unavailable on UIView? I don't see that in the header. I realize it's odd, but I'd expect to either get some sort of error in the editor or have it work since init ought to call init(frame:) w/ .zero.

It's not marked specially at all, but that makes it a convenience initializer, not a designated initializer, and that means it's not safe to call from a subclass. (What if you implemented init() but also init(frame:)?)

Comment by Amro Mousa (JIRA)

I see. Sure, that'd be fine. I ended up changing the offending classes to implement only init(frame:). We didn't specifically need init(). I'm honestly not sure why that pattern was adopted. Thank you.

I think the issue of the way the compiler failed stands. The improved logging was noticed and appreciated. If I could suggest an improvement there it would be to show the failing file name above the stack dump section (maybe replace the "<unknown>:0" bit) since it's the critical piece of information one would need to work around some other error similar to this.

This error message is coming from AST deserialization logic: for some reason, it thinks the init() on your subclass is trying to override an init() on UIView.

For the example you gave above, or for MomentFollowView, are there any attributes or modifiers on the initializer that you left out of the simplified form? Anything on the class? And is there a custom implementation of init() on UIView in an extension somewhere?

Comment by Amro Mousa (JIRA)

Thanks for your patience. I've been traveling and wasn't able to check. The views in question were direct UIView subclasses that attempted to define init() and there's no extension defining an implementation of init(). I'll try to get a repro case and close this ticket if I can't in the next few days.

Comment by Amro Mousa (JIRA)

Thanks for your patience here. I can't repro this in a standalone project and haven't seen it in ours recently so I'm going to close it.

We haven't been able to track it down either, but you're not the only one hitting it. Hopefully we'll get a reproducible test case soon.

Comment by Karl Puusepp (JIRA)

We also saw it appear when developing a completely unrelated feature. The only workarounds were either to force whole-module compilation or reorder some of the added sources in the project file.

I can totally believe that it's something that subtle. :-( If anyone has a project that they can share in a failing state (either here or at https://bugreport.apple.com) that would be greatly appreciated.

Comment by Karl Puusepp (JIRA)

Unfortunately I'm not able to share our project, but I have some more findings which hopefully could be of some use.

We use XcodeGen to generate our project files, which sorts target source files alphabetically. A new feature added several UIViewController subtypes into files beginning with an `ADR` prefix, thereby moving them to the top of the sources list.

As soon as any definition in one of those files inherits from UIViewController, UIView or even UIResponder this abort trap occurs (inherting from UIGestureRecognizer for example seems OK). Renaming the files to move them down the list (after regenerating the project) fixes the issue.

We have quite a lot of UIView and UIViewController subtypes that declare a no-argument `init`, but all these other usages have traditionally not caused any issues. But we've also never written view controllers starting with the letter A before.

Xcode 10.0, Swift 4.2, incremental compile mode. I tried creating a simple repro project with this file ordering logic, but it does not trigger the failure. Also happens on 10.1 Beta 2.

Comment by Alvar Hansen (JIRA)

@belkadan, we were able to create a project where this error reproduces. I've created a new ticket here: https://bugs.swift.org/browse/SR-9066