Comment by Ben A (JIRA)

I tried coming up with a smaller test case:
file1.swift

final class Wrapper<Wrapped> {
    let value: Wrapped
    init(value: Wrapped) { self.value = value }
}

final class Action {
    let isEnabled: Wrapper<Int>
    init() { self.isEnabled = Wrapper(value: 1) }
}

file2.swift

final class OtherWrapper<Wrapped> {
    let value: Wrapped
    init(value: Wrapped) { self.value = value }
}

extension Action {
    fileprivate var isEnabled: OtherWrapper<Bool> { return OtherWrapper(value: self.isEnabled.value != 0) }
}

However, that code compiles fine in Swift 4.1, the March 28 master snapshot, and April 20 master snapshot. But, the attached zipped project still doesn't build in the March 28 master snapshot, nor the latest April 20 master snapshot.

This is the main issue preventing us from verifying SR-7337 as well as testing the new batch mode.

Comment by Ben A (JIRA)

Okay I had a look at PRs that landed between the March 26 master snapshot (when this last worked) and the March 28 master snapshot (when this first regressed), and this PR seems like a likely culprit given the PR description + related bugs it closed: #15412

@hamishknight does that seem plausible? If so, would you mind having a look at the attached sample project?

Here's a reduced test case, it requires two modules:

Module A, a.swift:

public class Action<T> {
  public var i = 0
}

Module B, b.swift:

import A

extension Action {
  var i: String {
    let x: Int = i // in 4.1 no error, in the 2018-04-18 snapshot error: Cannot convert value of type 'String' to specified type 'Int'
    return String(x)
  }
}

The above compiles in 4.1, but doesn't in the 2018-04-18 snapshot.

I'm not sure what the exact cause of the problem is (and unfortunately I don't quite have the time to look into it in detail at the moment), though I agree that it's likely a result of #15412 – previously we would have given i two different overload types and therefore would have treated them as two distinct overloads, whereas now they have the same overload type (but we still allow the overload as it's in a different module).

Though i would have only had different overload types while Action had a generic placeholder, if we remove the <T> from the above example, then it will also fail to compile in 4.1 (what my change did was bring the generic behaviour in line with the non-generic).

cc @belkadan

Comment by Ben A (JIRA)

No problem

Thanks to both of you. Hm, I wonder if the type checker wasn't prepared to deal with property overloads.

@swift-ci create

Comment by Ben A (JIRA)

This is still an issue in the Xcode 10 beta. I know you all must have been super busy leading up to today's announcements; just wanted to flag this again as it's the major blocker for us doing any beta testing, batch mode testing, etc. Thanks!

We saw this in WWDC 18 lab that this issue stops users from using Xcode 10 with Pods.

cc @DougGregor

#18488

The above linked PR resolves the issue in Swift 5 under Swift 4 compatibility mode. I’ve filed https://bugs.swift.org/browse/SR-8619 to track a broader Swift 5 mode change where we no longer shadow another module’s property overload regardless of whether the two properties are defined in extensions of generic types.