This is a temporary solution that implements swift_newtype(enum) as
though it were written swift_newtype(struct). This is to work around
to the fact that a String-backed enum does not actually have a String
stored, and a struct is closer to reflecting that storage
properly. Struct provides most of the functionality and appearance for
now, though it does not allow for switching over the values.
Full support for swift_newtype(enum) as a Swift enum is forthcoming.
This introduces support for swift_newtype(struct) attribute (also
known as swift_wrapper). The Clang importer will create a brand new
struct corresponding to the annotated typedefs, which has a backing
raw value. Globals of that type are imported as static members on the
struct.
Additionally, this interacts seamlessly with prior import-as-member
work, meaning that the newly created type can be imported onto. Tests
included.
While inferring get/set, we paired them up even when one of them was
available through a custom objc header (e.g. a private
header). Instead, fail to pair them up. Test case added.
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.
For the most part this was just "check isInstanceProperty"; the one feature not yet implemented
is the emission of ObjC metadata for class properties.
rdar://problem/16830785
When importing members of an NS_OPTIONS (aka an option set), mark imported
members that have a value of 0 with an unavailable error. This produces an
experience like this:
x = NSRuncingOptions.none // expected-error {{'none' is unavailable: use [] to construct an empty option set}}
This is important to do, because option set members with a value of zero
do not act like members of the option set. For example, they always fail a
"contains" check.
This ensures their bodies are fragile in SIL. While they can
be synthesized again, this change will avoid tripping up the
SIL verifier after some upcoming changes.
Part of https://bugs.swift.org/browse/SR-267.
Computes the generic signature correctly for protocol extensions. Sets
the correct function and interface type when forming the imported
protocol member. This makes import-as-protocol-member work and fixes
the disappearing return value issue in protocols.
This was added at some point to make 'import Foundation' faster in the REPL.
What we really care about though is not delaying synthesis of the rawValue
accessors (those are synthesized on demand anyway), but delaying the
conformance check to RawRepresentable.
Moves CFPointeeInfo into CFTypeInfo.h/cpp, so that other parts of the
importer can re-use the logic for reasoning about CF types. This will
be needed by the import as member inference system to reason about
effective Clang contexts.
For function that we are importing as init, if there's dangling words
after the "Create" or "Make", we move them onto the first argument
label. This introduces the creation of an empty tuple parameter when
that init has no arguments.
Expands support for inference of computed properties, whether instance
or static, to include get-only. Adds test cases for both inference and
manual annotation for static computed properties.
When a global function is determined to be a lone getter or a
getter/setter pair, import it as a property. Handle global, instance,
and static properties.
As part of this, generalize importAsMethod to also handle static
methods and map pointer-to-non-const arguments to 'mutating' methods.
When printing the interface for a (sub)module, make sure that we only
print those extensions that were created to hold that submodule's
globals that were imported as members.
Print module functionality hooked up to import global functions a
methods, if dictated by the swift_name attribute. Test case included.
No SILGen support yet.
Wire up the extensions created when importing globals-as-members via
the same mechanisms we use for Objective-C categories, e.g.,
implementing loadAllExtensions() to find the extensions and lazily
loading their members via the member loader. Addresses most of my
comments on the way extensions were wired in.
Extend our testing for importing globals as members to two different
submodules, so we can see the separation of extensions.
As part of this, fold getOrCreateExtension into importDeclContextOf.
This adds initial functionality to import as initializer declarations
that have been swift_name declared to be inits.
SILGen support is still lacking for these inits.
