These are tests that fail in the next commit without this flag. This
does not add -verify-ignore-unrelated to all tests with -verify, only
the ones that would fail without it. This is NFC since this flag is
currently a no-op.
A change in the new clang branch seems to have caused it to start applying SwiftNameAttrs to forward declarations. We have apparently always tried to add these forward declarations to the lookup tables in PCH files, but never diagnosed the resulting failures because they did not have SwiftNameAttrs. Now they do, so we started emitting incorrect warnings.
We *probably* don’t need to process these at all, but there’s a risk of unintended behavior changes from that; instead, this commit takes a conservative approach and simply suppresses the warnings like we always have.
Fixes rdar://74710976.
1. Set the diagnostic location to where the attribute was written (or
to the Clang decl's source, if the attribute came from API notes)
2. Add a note to contact the owners of the framework to make it clear
that the client of the framework didn't do anything wrong.
rdar://problem/52736145
There are multiple ways in which the Clang importer can produce an
initializer, and we have existing name shadowing rules to decide on
the best. Extend those rules to cover the case where a
Clang-importer-synthesized initializer collides with a C function
imported as an initializer. There's technically no reason to do the
latter because the former already exists, but some frameworks
currently depend on this.
Prior to this, the constraint solver was preferring the synthesized
initializer already (which is the right thing to do), for the wrong
reasons.
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
That is, if a member is redeclarable, use the module of the definition
if possible, and the canonical declaration otherwise. This is
consistent with what we do when we actually import the declaration.
Without this, we can end up dropping declarations.
rdar://problem/32816381
