Optional swift_newtype types are @objc if the raw type would be @objc.

[jrose-apple]

This was causing issues where the compiler rejected overrides of imported members as being non-ObjC-compatible, even though the type was exactly the same as what the Clang importer was using.

https://bugs.swift.org/browse/SR-2344

---

Before merging this pull request to apple/swift repository:

• Test pull request on Swift continuous integration.

Triggering Swift CI

The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:

Smoke Testing

Platform	Comment
All supported platforms	@swift-ci Please smoke test
All supported platforms	@swift-ci Please smoke test and merge
OS X platform	@swift-ci Please smoke test OS X platform
Linux platform	@swift-ci Please smoke test Linux platform

A smoke test on macOS does the following:

1. Builds the compiler incrementally.
2. Builds the standard library only for macOS. Simulator standard libraries and
   device standard libraries are not built.
3. lldb is not built.
4. The test and validation-test targets are run only for macOS. The optimized
   version of these tests are not run.

A smoke test on Linux does the following:

1. Builds the compiler incrementally.
2. Builds the standard library incrementally.
3. lldb is built incrementally.
4. The swift test and validation-test targets are run. The optimized version of these
   tests are not run.
5. lldb is tested.

Validation Testing

Platform	Comment
All supported platforms	@swift-ci Please test
All supported platforms	@swift-ci Please test and merge
OS X platform	@swift-ci Please test OS X platform
OS X platform	@swift-ci Please benchmark
Linux platform	@swift-ci Please test Linux platform

Lint Testing

Language	Comment
Python	@swift-ci Please Python lint

Note: Only members of the Apple organization can trigger swift-ci.

[jrose-apple]

@milseman, @DougGregor, mind reviewing?

I'm thinking this is probably too risky for Swift 3.0, but it's still worth getting into master. It stinks because you actually can't override some things, though.

@swift-ci Please test

[jrose-apple]

Linux failure unrelated. I didn't even mean to test Linux. This only affects @objc.

[DougGregor]

This LGTM. I'm inclined to say we should take this for Swift 3.0, because there's no good workaround for "I can't express this override of an Objective-C method" while there is a workaround for the cases where this could potential break things (e.g., errant @objc inference can be turned off with @nonobjc).

[jrose-apple]

Okay, I'll make a PR.

[jrose-apple]

Oh, shoot, the patch-as-is isn't strictly correct because it returns the wrong conformance. We want to check the underlying type's conformance, but use the wrapper type's.

[jrose-apple]

Can you think of a test case where this would break?

[DougGregor]

I don't think anyone uses the actual conformance.

[jrose-apple]

Okay, opened #4360.