That is, if we encounter a property declaration, and a no-argument
method is visible, it's only a problem if there's not already a
property there. (Arguably this means that it's either not a problem at
all, or that we shouldn't be mirroring protocol methods onto classes
if there's a conflicting property, but this change doesn't attempt to
answer that.)
https://bugs.swift.org/browse/SR-8490
This enables additional tests for the ClangImporter. This found a
missing piece in the `-enable-objc-interop` work that was done
previously. Address that and enable the tests. There are now the
following failing tests on Linux:
* sdk - depends on Foundation (not hermetic, see SR-7572)
* mixed-nsuinteger - depends on Foundation (not hermetic, see SR-7572)
* import-mixed-with-header-twice - requires apple/swift PR#16022
* can_import_objc_idempotent - requires apple/swift PR#16022
* objc_protocol_renaming - requires apple/swift PR#16022
In the case of the nullability change, this snuck all the way past the
type checker to result in an assertion failure in SILGen; if
assertions were turned off, it continued all the way through IRGen
before the LLVM verifier caught it.
We get in this situation because ObjCPropertyDecls in Clang aren't
considered "redeclared" like most other entities. Instead, they're
just matched up by name in a few places. At first I considered trying
to handle such canonicalization post hoc in Swift's importer, but that
would have turned into plenty of work for something that rarely comes
up at all. Instead, this patch just drops the setter from such a
redeclared property if it doesn't match up.
Clang itself should diagnose these kinds of mismatches; that's been
filed as rdar://problem/29536751 for nullability and a similar
rdar://problem/29222912 for changing types in general.
rdar://problem/29422993
