Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SR-7059] Failed to infer generic type parameter in Xcode 9.3 beta 3 #49607

Closed
sharplet opened this issue Feb 22, 2018 · 16 comments
Closed

[SR-7059] Failed to infer generic type parameter in Xcode 9.3 beta 3 #49607

sharplet opened this issue Feb 22, 2018 · 16 comments
Assignees
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself regression swift 4.1 type checker Area → compiler: Semantic analysis

Comments

@sharplet
Copy link

Previous ID SR-7059
Radar rdar://problem/37790062
Original Reporter @sharplet
Type Bug
Status Closed
Resolution Done
Environment

Xcode Version 9.3 beta 3 (9Q117m)
macOS High Sierra Version 10.13.3 (17D47)

Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, 4.1Regression, TypeChecker
Assignee @sharplet
Priority Medium

md5: 604d9e44d4f998c77ba621c74606f260

Issue Description:

To reproduce:

git clone https://github.com/Thomvis/BrightFutures
cd BrightFutures
carthage bootstrap --no-build
xcodebuild -workspace BrightFutures.xcworkspace -scheme BrightFutures-iOS

Error message:

.../Thomvis/BrightFutures/Sources/BrightFutures/Result+BrightFutures.swift:51:21: warning: result of call is unused, but produces '_'
                    complete(res.analysis(ifSuccess: {
                    ^       ~~~~~~~~~~~~~~~~~~~~~~~~~~
.../Thomvis/BrightFutures/Sources/BrightFutures/Result+BrightFutures.swift:48:16: error: generic parameter 'T' could not be inferred
        return Future { complete in
               ^
.../Thomvis/BrightFutures/Sources/BrightFutures/Future.swift:34:20: note: 'T' declared as parameter to type 'Future'
public final class Future<T, E: Error>: Async<Result<T, E>> {
                   ^
.../Thomvis/BrightFutures/Sources/BrightFutures/Result+BrightFutures.swift:48:16: note: explicitly specify the generic arguments to fix this issue
        return Future { complete in
               ^
                     <Any, <#E: Error#>>
@belkadan
Copy link
Contributor

cc @rudkx, @xedin

@swift-ci create

@xedin
Copy link
Member

xedin commented Feb 23, 2018

Looks like this has been broken for a while now, I've tried with snapshot from 1/30 (the earliest I have) and it fails there too... Going to try to get some more nightlies and see when it started.

@xedin
Copy link
Member

xedin commented Feb 23, 2018

Here is the minimized test-case:

protocol A {
  associatedtype V
  associatedtype E: Error

  init(value: V)
  init(error: E)

  func foo<U>(value: (V) -> U, error: (E) -> U) -> U
}

enum R<T, E: Error> : A {
  case foo(T)
  case bar(E)

  init(value: T) { self = .foo(value) }
  init(error: E) { self = .bar(error) }

  func foo<R>(value: (T) -> R, error: (E) -> R) -> R {
    fatalError()
  }
}

protocol P {
  associatedtype V

  @discardableResult
  func baz(callback: @escaping (V) -> Void) -> Self
}

class C<V> : P {
  func baz(callback: @escaping (V) -> Void) -> Self { return self }
}
class D<T, E: Error> : C<R<T, E>> {
  init(fn: (_ ret: @escaping (V) -> Void) -> Void) {}
}

extension A where V: P, V.V: A, E == V.V.E {
  func bar() -> D<V.V.V, V.V.E> {
    return D { complete in
      foo(value: { promise in promise.baz { result in } },
          error: { complete(R(error: $0)) })
    }
  }
}

I'm not exactly sure what is going on yet but it's related to - 3b7e555

@xedin
Copy link
Member

xedin commented Feb 24, 2018

Ok think is actually interesting because `foo` returns `U` and `baz` returns `Self` but `error:` branch returns Void which means that we are trying to infer `U` to be `Self.V` and `Void` which are not convertible. It looks like in 4.1 (this has failing on 4.0) we ended up inferring `U` to be `Void` somehow, trying to figure out how that happened.

@xedin
Copy link
Member

xedin commented Feb 24, 2018

@sharplet as a work around for now you can add return () after `analysis` call.

@xedin
Copy link
Member

xedin commented Feb 24, 2018

@rudkx Looks like constraint edge contraction changes exposed a problem in the `getPontentialBindings` once again, because for this particular expression it changes order in which we attempt them.

@xedin
Copy link
Member

xedin commented Feb 24, 2018

Previously `Void` be inferred because we tried result type of the outermost closure first and `U` is convertible to that type.

@xedin
Copy link
Member

xedin commented Mar 1, 2018

#14846 is going to address this problem.

@sharplet please use one of the next nightly snapshots to verify. Thank you for the report!

@e28eta
Copy link
Mannequin

e28eta mannequin commented Mar 15, 2018

@xedin Did this fix get reverted? I see #15069, and I'm still seeing the issue in Xcode 9.3b4.

I'm not sure how to tell how recent the swift build included in Xcode is, and I can't tell if #15069 was a reversion because you found a better way, or if this issue should be re-opened?

@xedin
Copy link
Member

xedin commented Mar 15, 2018

@e28eta It got reverted by I've made it work in a different way via #15134

@e28eta
Copy link
Mannequin

e28eta mannequin commented Mar 15, 2018

Thanks so much! I've subsequently found the instructions on running nightlies, and I do see this fixed in master (but not 4.1?).

I appreciate the fix, and I also appreciate the papertrail between this issue and the PR that fixed it.

@xedin
Copy link
Member

xedin commented Mar 15, 2018

Happy to help! Sorry but you'll have to use workaround for now since this was too late in the cycle to make it to 4.1

@AnnaZaks
Copy link
Mannequin

AnnaZaks mannequin commented Jul 26, 2018

@sharplet, Could you verify if the problem is fixed and if so move the JIRA to "Closed"?
Thanks!
Anna

@sharplet
Copy link
Author

The same commit (6.0.0, 8659746df02d8f62a112eda288f4f2f3bab368f) appears to fail in a different way on Xcode 9.4:

Compiling Result+BrightFutures.swift

⚠️  /Users/adsharp/src/Thomvis/BrightFutures/Sources/BrightFutures/Result+BrightFutures.swift:51:21: result of call is unused, but produces '_'

                    complete(res.analysis(ifSuccess: {
               ^



❌  /Users/adsharp/src/Thomvis/BrightFutures/Sources/BrightFutures/Result+BrightFutures.swift:48:16: generic parameter 'T' could not be inferred

        return Future { complete in
                    ^       ~~~~~~~~~~~~~~~~~~~~~~~~~~

@xedin
Copy link
Member

xedin commented Jul 27, 2018

@sharplet It seems like the fix didn't make it to 9.4 but I've tried to build the BrightFutures project with 10 beta 4 and it compiled just fine, could you please try that out as well?

@sharplet
Copy link
Author

Yes, it compiled fine in beta 4 for me!

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself regression swift 4.1 type checker Area → compiler: Semantic analysis
Projects
None yet
Development

No branches or pull requests

4 participants