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-3788] Code not compiling in Swift 3.1 #46373

Closed
swift-ci opened this issue Jan 30, 2017 · 11 comments
Closed

[SR-3788] Code not compiling in Swift 3.1 #46373

swift-ci opened this issue Jan 30, 2017 · 11 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself

Comments

@swift-ci
Copy link
Collaborator

swift-ci commented Jan 30, 2017

Previous ID SR-3788
Radar rdar://problem/30268530
Original Reporter diegosanchezr (JIRA User)
Type Bug
Status Resolved
Resolution Won't Do
Environment

Xcode 8.3 beta (8W109m)
Compiler: bundled with Xcode and swift-3.1-DEVELOPMENT-SNAPSHOT-2017-01-22-a

Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, 3.1Regression
Assignee None
Priority Medium

md5: a369975f782115c97440ad126c696d89

Issue Description:

Hi,

Our project doesn't compile on Swift 3.1 but it does on Swift 3.0

STR

clone: https://github.com/badoo/Chatto
open ./ChattoApp/ChattoApp.xcworkspace
compile ChattoApp target

Issues:

a)

/Users/diegosanchez/branches/Chatto/ChattoAdditions/Source/Input/Photos/PhotosInputDataProvider.swift:144:42: error: cannot perform mutating operation: 'self.photosDataProvider' is a 'let' constant
        self.photosDataProvider.delegate = self
                                         ^
/Users/diegosanchez/branches/Chatto/ChattoAdditions/Source/Input/Photos/PhotosInputDataProvider.swift:138:13: note: change 'let' to 'var' to make it mutable
    private let photosDataProvider: PhotosInputDataProviderProtocol
            ^~~
            var

This one I agree with the compiler, it shouldn't compile and should be fixed manually by adding a class constraint to PhotosInputDataProviderProtocol

b)

/Users/diegosanchez/branches/Chatto/ChattoAdditions/Source/Input/Photos/PhotosInputView.swift:189:53: error: ambiguous use of 'collectionView'
        self.addConstraint(NSLayoutConstraint(item: self.collectionView, attribute: .leading, relatedBy: .equal, toItem: self, attribute: .leading, multiplier: 1, constant: 0))
                                                    ^
/Users/diegosanchez/branches/Chatto/ChattoAdditions/Source/Input/Photos/PhotosInputView.swift:195:10: note: found this candidate
    func collectionView(_ collectionView: UICollectionView, numberOfItemsInSection section: Int) -> Int {
         ^
/Users/diegosanchez/branches/Chatto/ChattoAdditions/Source/Input/Photos/PhotosInputView.swift:199:10: note: found this candidate
    func collectionView(_ collectionView: UICollectionView, cellForItemAt indexPath: IndexPath) -> UICollectionViewCell {
         ^
/Users/diegosanchez/branches/Chatto/ChattoAdditions/Source/Input/Photos/PhotosInputView.swift:211:10: note: found this candidate
    func collectionView(_ collectionView: UICollectionView, didSelectItemAt indexPath: IndexPath) {
         ^

Once fixed that manually, by creating a local variable referencing self.collectionView, I get this other one:

c)

/Users/diegosanchez/branches/Chatto/ChattoApp/ChattoApp/Source/FakeDataSource.swift:106:20: error: cannot convert value of type '(didAdjust: Bool)' to expected argument type 'Bool'
        completion((didAdjust: didAdjust))
                   ^~~~~~~~~~~~~~~~~~~~~~
                                          as! Bool

Commenting that line leads to...

d)

Undefined symbols for architecture x86_64:
  "__TIFC9ChattoApp40BaseMessageCollectionViewCellAvatarStylecFT6colorsVC15ChattoAdditions41BaseMessageCollectionViewCellDefaultStyle6Colors18bubbleBorderImagesGSqVS2_18BubbleBorderImages_16failedIconImagesVS2_16FailedIconImages15layoutConstantsVS1_44BaseMessageCollectionViewCellLayoutConstants13dateTextStyleVS2_13DateTextStyle11avatarStyleVS2_11AvatarStyle_S0_A_", referenced from:
      __TFC9ChattoApp22DemoChatViewController23createPresenterBuildersfT_GVs10DictionarySSGSaP6Chatto32ChatItemPresenterBuilderProtocol___ in DemoChatViewController.o
@belkadan
Copy link
Contributor

belkadan commented Jan 30, 2017

a) I agree with you, I'm surprised it ever compiled. I don't think we'll fix this one.
b) This one we've seen before; it's tracked internally at Apple by rdar://problem/30176166.
c) This one is still a problem. 1-tuples aren't supposed to be allowed at all in Swift, so the fact that you can write this at all is an error, but now it's a source compatibility issue and we can't change it until Swift 4.
d) This one is rdar://problem/30167924.

Let's use this bug to track (c), since that's the only one I don't think we've seen before.

@belkadan
Copy link
Contributor

belkadan commented Jan 30, 2017

Reduced:

func foo(completion: ((didAdjust: Bool)) -> Void) {
    completion((didAdjust: true))
}

@belkadan
Copy link
Contributor

belkadan commented Jan 30, 2017

@swift-ci create

@slavapestov
Copy link
Member

slavapestov commented Feb 1, 2017

Are 1-tuples really banned? If so, we should prohibit them in Swift 4 mode. Right now we have some half-assed logic in a few places that diagnoses when they come up, but it's not very thorough.

@swift-ci
Copy link
Collaborator Author

swift-ci commented Feb 2, 2017

Comment by Diego (JIRA)

If I can say something, I'd prefer to have the ability to use 1-tuples. Maybe it's a workaround here for the lack of labeled arguments in closure, but maybe there are some other uses for them. I don't see them hurting from the user point of view.

Related to this, do you have plans to recover labeled arguments at call site for closures in Swift 4? If I remember correctly that was the plan moving forward in that polemic evolution thread.

@belkadan
Copy link
Contributor

belkadan commented Feb 2, 2017

These are discussions for swift-evolution, not the bug tracker. :-) The priorities here are

(1) make sure things that worked in Swift 3.0 work in Swift 3.1
(2) get the implementation model closer to the current language model.

All tuple types contain two or more types, except for Void which is a type alias for the empty tuple type, (). A single parenthesized type is the same as that type without parentheses.

(https://developer.apple.com/library/prerelease/content/documentation/Swift/Conceptual/Swift_Programming_Language/Types.html#//apple_ref/doc/uid/TP40014097-CH31-ID448)

cc @DougGregor, @jckarter

@jckarter
Copy link
Member

jckarter commented Feb 2, 2017

I would say conceptually that unlabeled 1-tuples do exist, but that they are synonymous with the one element type. The prohibition against labeled 1-tuples was motivated by type system problems dealing with the slushy rules around labeled/unlabeled tuple conversions, and the interaction with edge cases due to unlabeled 1-tuples being non-canonical. We've significantly reduced the scope of the problem by tightening up the compound-function-name and multiple-function-arguments models since Swift 1, so maybe that's less problematic than it used to be when every function argument was a tuple. We could also tighten up the conversion rules around tuple labels to eliminate the circular relationship between labeled and unlabeled tuples—maybe say you can convert labels off, but not back on?

@jckarter
Copy link
Member

jckarter commented Feb 6, 2017

Talking to Slava, it sounds like it would be pretty risky and fragile to try to continue accepting this code in 3.1, since a lot of the type checker has "moved on" and jettisoned the special cases that were necessary to try to handle single-element tuples in various places. In #7279 I improved the code that checks for them so you at least get a clearer error message when you try to summon them.

@swift-ci
Copy link
Collaborator Author

swift-ci commented Mar 24, 2017

Comment by Slipp Douglas Thompson (JIRA)

Heads-up: I just saw this bug mentioned in the Xcode 8.3 beta 5 Release Notes, in which it's recommended to replace func foo(x: ((y: Int)) ->; Int) with func foo(x: (Int) ->; Int)). However, the suggested replacement won't actually compile— it has 2 opening
“(”s and 3 closing “)”s.

I believe this is just a double-“)” typo; though it's probably worth fixing before the Xcode 8.3 final Release Notes, since the way its currently written could confuse a bunch of users and lead to a bunch of extra Swift bugs being filed over nothing.

@swift-ci
Copy link
Collaborator Author

swift-ci commented Mar 25, 2017

Comment by Myke Olson (JIRA)

Thanks for the heads up, capnslipp (JIRA User). We're working on getting the release note updated.

@belkadan
Copy link
Contributor

belkadan commented Feb 21, 2018

Closing this issue now that there's a good diagnostic.

@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
Projects
None yet
Development

No branches or pull requests

4 participants