Infer selectors from protocols for property accessors too.

[jrose-apple]

Most property accessors have selectors matching their protocols, but not all. Don't force the user to write @objc explicitly on an accessor, which isn't even possible for stored properties.

Groundwork for rdar://problem/28543037.

[jrose-apple]

This still has two problems:

• At the bottom of TypeChecker::findWitnessedObjCRequirements there's a section about inherited conformances that I don't quite understand, but that probably needs to do the same thing.

• There's an existing problem that we get duplicate diagnostics when a witness doesn't have the correct type, as seen in test/ClangImporter/objc_parse.swift. I think this is because calling lookupConformance in findWitnessedObjCRequirements is going to try to validate the conformance again even after we've already diagnosed it, but I don't know what to do about it.

@DougGregor, do you have any insight into either of these?

[jrose-apple]

(with expected failures)

@swift-ci Please smoke test

[slavapestov]

If a base class conforms to a protocol and a subclass implements an optional requirement, we don't record that anywhere. I think this is what that comment is referring to.

[slavapestov]

In general do we want to change things so that accessors have witnesses, instead of/in addition to the AbstractStorageDecl? We do this dance in a bunch of places where we check if we have an accessor, get its storage, lookup the witness and then get the right accessor from there.

[slavapestov]

Also it would be cool if a no-payload enum case could witness a read-only static property requirement :)

[jrose-apple]

(still with expected failures)

@swift-ci Please smoke test macOS

[DougGregor]

Yeah, the comment about inherited conformances is that the superclass can conform to some @objc protocol without implementing some of the optional requirements. Then, the subclass can come in and implement an optional requirement---and we need to make sure we infer the selector there. At some point, we could/should have inherited protocol conformances compute and record these witnesses to optional requirements, but for now we don't, so this code looks for them explicitly.

[DougGregor]

Regarding the double-diagnostic, it seems like we should be recording an erroneous/missing witness when there is a type mismatch, and shouldn't diagnose any problems with that requirement in that conformance later.

[DougGregor]

And, thanks for working on this!

[jrose-apple]

Okay, added support for inference from optional requirements as well. Depends on (well, includes) #6698 now. Any more comments, @DougGregor or @slavapestov?

(I'm not touching the larger issue of accessor requirements for now; that's more change than I'd want to pull into Swift 3.1.)

@swift-ci Please test

[swift-ci]

Build failed
Jenkins build - Swift Test OS X Platform
Git Commit - 9225e25ab5790d88f3fc425736aa3adb010cb5f3
Test requested by - @jrose-apple

[swift-ci]

Build failed
Jenkins build - Swift Test Linux Platform
Git Commit - 9225e25ab5790d88f3fc425736aa3adb010cb5f3
Test requested by - @jrose-apple

[DougGregor]

No more comments, thanks @jrose-apple