Referring to an argument in another function!
%0 = call i8** @swift_getGenericWitnessTable(%swift.generic_witness_table_cache* @_TWGC6Eureka8CheckRowS_7RowTypeS_, %swift.type* %0, i8** null) #​6, !dbg !4102
LLVM ERROR: Broken function found, compilation aborted!

Yikes. @jckarter, who would be good to check this out?

Sounds like a regression from @rjmccall's work.

John's out this week. Let me see if I can get a workaround in place to keep 2.2 from regressing.

When compiling in 7D141l, I get a disembodied error message:

<unknown>:0: error: initializer requirement 'init' can only be satisfied by a `required` initializer in the definition of non-final class 'Section'

mtnbarreto (JIRA User) To keep you up-to-date: Eureka's managed to reveal quite a chain of regressions. The aforementioned disembodied error message was fixed by @DougGregor in #1330 @slavapestov fixed a SIL generation regression in #1359 but we hit another one after that, which we're currently investigating. We also stumbled into an LLVM generation bug when experimenting with workarounds.

Comment by Martin Barreto (JIRA)

@jckarter Thanks for the update and the great work! Can we expect to get this fixed before XCode7.3 official release?

mtnbarreto (JIRA User), @slavapestov's still looking into it, but from discussion with him it sounds like a proper fix might be at risk at this point. You might be able to adopt a workaround though. AIUI the problem arises from a protocol extension with a base class constraint on `Self` and an associated type satisfied by the base class constraint:

protocol P { associatedtype T }
class Base { typealias T = Int }
extension P where Self: Base { ... }

The compiler has trouble resolving associated type requirements that should be satisfied by base class constraints. You can avoid the problem by adding a redundant same-type constraint to the associated type in the protocol extension:

extension P where
  Self: Base,
  // FIXME: Should be redundant with the above
  T == Int
{ ... }

Comment by Martin Barreto (JIRA)

@jckarter Thanks for the suggestions. I was able to "fix" most of the library issues by making some changes on the library protocol hierarchy, extension and generic type constraints as you suggested.

However I ran into this issue: http://www.openradar.me/23358609 trying to conform to `RangeReplaceableCollectionType` which among other things requires a init(). Even though I provide a `public required init()` implementation the compiler keeps returning `Initializer requirement 'init' can only be satisfied by a `required` initializer in the definition of non-final class 'Section'`. Making `Section` class final, fixes the problem but I can not make `Section` final since I need to extend it.

Any help would be greatly appreciated!! I can provide any additional information and the updated code if you want to look into it.

We encountered and fixed that issue as well. I think it's fixed in the 2.2 branch now, if you want to try a newer Xcode beta or Swift.org toolchain.

The last of the problems with this project was fixed by

02dd1e4

on the Swift master branch. Unfortunately, there's too long of a trail of potentially-destablizing fixes to pull all of these into Swift 2.2

Comment by Martin Barreto (JIRA)

@jckarter @DougGregor It seems http://www.openradar.me/23358609 no longer happens in https://ci.swift.org/view/Packages/job/oss-swift-2.2-package-osx/ws/swift-2.2-SNAPSHOT-2016-02-24-a-osx.tar.gz . That's great!

I only have one compilation error left to make the library work on 2.2.
```
Assertion failed: (Conformance.getDeclContext()->isGenericContext()), function buildAccessFunction, file /Users/buildnode/jenkins/workspace/oss-swift-2.2-package-osx/swift/lib/IRGen/GenProto.cpp, line 2167.
0 swift 0x0000000103b530bb llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 43
1 swift 0x0000000103b52376 llvm::sys::RunSignalHandlers() + 70
2 swift 0x0000000103b53762 SignalHandler(int) + 322
3 libsystem_platform.dylib 0x00007fff99980eaa _sigtramp + 26
4 swift 0x00000001045afc0d FirstTarget + 68869
5 swift 0x0000000103b53576 abort + 22
6 swift 0x0000000103b53551 __assert_rtn + 81
7 swift 0x000000010152a60a swift::irgen::IRGenModule::emitSILWitnessTable(swift::SILWitnessTable*) + 2474
8 swift 0x00000001014a7df1 swift::irgen::IRGenModuleDispatcher::emitGlobalTopLevel() + 737
9 swift 0x000000010154f0d6 performIRGeneration(swift::IRGenOptions&, swift::ModuleDecl*, swift::SILModule*, llvm::StringRef, llvm::LLVMContext&, swift::SourceFile*, unsigned int) + 1110
10 swift 0x000000010154f676 swift::performIRGeneration(swift::IRGenOptions&, swift::SourceFile&, swift::SILModule*, llvm::StringRef, llvm::LLVMContext&, unsigned int) + 70
11 swift 0x000000010140b4e2 frontend_main(llvm::ArrayRef<char const*>, char const*, void*) + 11890
12 swift 0x0000000101404719 main + 2905
13 libdyld.dylib 0x00007fff8f61c5ad start + 1
Stack dump:
```
This is my latest code base after fixing the majority of issues and warnings: https://github.com/xmartlabs/Eureka/tree/fix/Xcode7-3. If we remove DateInlineRow.swift from framework target it compiles otherwise this error is thrown...

Something interesting is that PickerInlineRow.swift is pretty similar to DateInlineRow but it compiles. The only difference from DateInlineRow is that PickerInlineRow is generic so I made DateInlineRow a generic type adding <T> and it compiles successfully.

```
public final class DateInlineRow: _DateInlineRow, RowType, InlineRowType { // <<<<<<<< ----— DateInlineRow<T> makes it compile.
required public init(tag: String?) {
super.init(tag: tag)
}
....
}
```

@DougGregor I think this issue should not be closed yet since Eureka generic types, protocols hierarchy and protocol oriented adoption are not that complex and it's just using swift standard features. On top of that it was working properly prior swift 2.2.

I'm waiting for CI master branch snapshot to see if it works using it.

It's been fixed for Swift 3, and we determined that it's too destabilizing to take more changes into the Swift 2.2 branch to address this regression, given that there are workarounds. I know it's frustrating to have Swift 2.2 ship with a regression on your project.

Comment by Martin Barreto (JIRA)

for now i will add a typealias so i don't introduce any breaking changes to Eureka (at least for the basic usage)

public typealias DateInlineRow = DateInlineRow_<NSDate>