This can come up when we use import-as-member to turn top-level functions
into methods in an @objc class. Previously dynamic lookup would find
these, causing a SILGen crash.
Fixes <rdar://problem/36492980>.
Right now the ClangImporter relies on Sema to synthesize typealiases
in some cases, which doesn't work if a Sema instance is not available,
for example when the ClangImporter is asked to import a declaration
while deserializing SIL during optimization.
Begin addressing this by synthesizing typealiases for the following
conformances:
- ExpressibleByArrayLiteral.ArrayLiteralElement while importing
OptionSets.
- RawRepresentable.RawValue while importing raw-valued enums.
- ObjectiveCBridgeable._ObjectiveCType while importing bridged
newtypes.
Until further changes land, this is mostly NFC, except for a change
in generated interface printing where the new typealiases are now
explicitly shown.
Note that non-bridged newtypes whose raw type is ObjectiveCBridgeable
still rely on associated type inference, because the ClangImporter
cannot safely "copy" the _ObjectiveCType typealias from the raw type
to the newtype, for various reasons mostly having to do with
circularity. Subsequent patches will address this, in a rather novel
fashion that will shock you.
Rather than requiring associated type witness inference to go and
figure out the Element type from the other witnesses for imported
OptionSet types, synthesize the typealias directly in the
importer. This is a simplification and a performance optimization.
Rather than requiring associated type witness inference to go and
figure out the RawValue type from the rawValue witnesses for imported,
RawRepresentable types, synthesize the typealias directly in the
importer. This is a simplification and a performance optimization.
We already have an option to skip /all/ unavailable decls. Singling
out the ones that are specifically unavailable-in-Swift just makes
testing harder.
This will not affect interface generation in Xcode, which sets that
option to skip all unavailable decls.
We could support this in the future but right now it's causing problems.
There's also a potential ambiguity issue here where a protocol and class
could have the same name.
In addition to updating the importer, remove the two entries from the
CryptoTokenKit API notes that were trying to use this feature.
rdar://problem/27990168
More generally, an unavailable initializer shouldn't stomp on an
available initializer, because it's possible that (for example) a
designated initializer will be unavailable but a factory initializer
will be available, so one still construct objects of that type.
Fixes rdar://problem/26238032.
It's possible for swift_name to make a global declaration into a
member of another entity that has not been seen yet. In such cases,
delay resolution until the end of the translation unit (module). Fixes
the rest of rdar://problem/25502497.
Some of the callers to importDeclContextOf could and should have
passed an effective context, but didn't, so (e.g.) an enum defined in
C couldn't be mapped to a nested type in Swift. Eliminate the
single-argument importDeclContextOf honeypot so we remember to pass
down the effective Clang context. Fixes rdar://problem/25502497.
