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.
When importing as a member, we want a single unique extension
declaration per type per Clang submodule. This adds the mapping,
switches import-as-member VarDecl importing to use it, and forces the
created extensions to show up.
The swift_name string format now supports "getter:" and "setter:"
prefixes to indicate that a function is the getter or setter of a
Swift-synthesized property. Start parsing these DeclNames and make
sure they're reflected in the Swift name lookup tables.
[Clang update required]
A swift_name attribute on a global declaration can specify a dotted
name (e.g., SomeStruct.member) to map that global into a member of the
(Swift-)named type. Handle this mapping in DeclName parsing, plumb it
through importFullName, and cope with it in the Swift name lookup
tables (tested via the dump) and importing into a Swift DeclContext
(as-yet-untested). Part of SE-0033.
Previously, the "effective context" parameter to importFullName was
used only during the construction of Swift name lookup tables, so we
can associate each declaration with a context. Expand the role of
"effective context" so it is always a part of ImportedName and is also
used by importDecl when actually importing the enum declaration.
This is partially a cleanup, and partially staging for SE-0033, which
will require this functionality more broadly.
This reorganization allows adding attributes that refer to types.
I need this for a @_specialize attribute with a type list.
PrintOptions.h and other headers depend on these enums. But Attr.h
defines a lot of classes that almost never need to be included.
Rather than managing API notes directly in the Clang importer, tell
Clang where to find the API notes files and let it map them directly
to attributes. Then, use the existing attribute-mapping
mechanisms---with minor extensions for cases where Clang previously
didn't map some Swift-specific API notes---to get at that information.
There is a minor regression where we can no longer apply API notes to
declarations that don't have a specific Clang declaration. The
specific example (NSError's inherited init()) comes from
rdar://problem/21042412; we've regressed here, but the correct fix is
(and has always been) on the Objective-C side
(rdar://problem/19977891).
Finishes rdar://problem/24447420.
There's a group of methods in `DeclContext` with names that start with *is*,
such as `isClassOrClassExtensionContext()`. These names suggests a boolean
return value, while the methods actually return a type declaration. This
patch replaces the *is* prefix with *getAs* to better reflect their interface.
ns_error_domain can now be used to communicate with the ClangImporter
when an enum has an associated error domain string. In this case, when
we import it as a Swift enum, we can also synthesize a conformance to
_BridgedNSError.
This allows the creation of something like NS_ERROR_ENUM, in which the
developer can declare an enum for the purposes of error handling. Adds
Sema and executable tests demonstrating this funcionality.
In order for the imported ns_error_domain bridging to work, we have to
at some point forcibly pull in a _BridgedNSError conformance, as one
will not be pulled in normally. This is a problem, and is explicitly
signaled in the provided test case
Introduces new class, EnumInfo, just for the implementation of the
ClangImporter to encapsulate various computed information about the
enum we're importing.
This helps refactor some functionality, aids clarity, and also
prevents us from repeating calculations multiple times, as we were
doing with classifyEnum's macro-expansion tracking. Provides a base
where we can add more heavy lifting in classifyEnum in the future.
This is the beginning of the extension of the availability model
introduced in Swift 2.0 to support two interesting things: inlineable
code and binary frameworks not tied to an OS. The former is critical
to having a stable standard library that isn't shipped with a client app.
(For more information on both of these, see docs/LibraryEvolution.rst.)
The existing availability model enforces that API is not used unless
the developer has already guaranteed its existence. We want to reuse
this logic for these new purposes. Additionally, certain queries about
the AST are dependent on this type of information as well, e.g. "can I
assume this enum will not grow any additional cases?" If the enum comes
from the module being compiled, the answer is usually "yes", but not if
the code asking the question may be inlined into another binary!
(This latter purpose is currently served by ResilienceExpansion down at
the SIL level; my goal is to replace ResilienceExpansion with
AvailabilityContext. It's a bit heavier but would also allow additional
optimization in the future.)
This commit does not change any logic; it only wraps existing uses of
VersionRange in AvailabilityContext if they're not strictly referring to
the OS version.
The Clang importer generally imports a CF type under two names, one
with "Ref" and one without, which is needlessly redundant. Mark the
"Ref" versions as deprecated (with a rename to the non-"Ref" version)
now as a migration step toward removing them entirely (gated by
-enable-omit-needless-words). Fixes rdar://problem/16888940.
CF types are generally imported twice, once with the "Ref" and once
without the "Ref", unless the non-"Ref" version would conflict with
some other declaration (e.g., an Objective-C class of the same name).
The logic to create both versions was a bit convoluted, and tended to
return the "Ref" version as the primary declaration, which conflicts
with our general inclination to use the non-"Ref" version. Now we create
the non-"Ref" version directly and then create the aliased "Ref" version
as an alternate declaration. The "Ref" version is a typealias of the
non-"Ref" version, and the "Ref" version is never used anywhere else
in the AST.
Also, improve the conflict resolution for cases where the only
conflicting declaration is an opaque tag used to declare the CF type
itself, e.g.,
typedef struct CGImage *CGImageRef;
These cases used to be considered conflicts, but they are benign
because the underlying struct will never actually be imported. Make
them not conflicts, so we get the preferred name "CGImage" rather than
"CGImageRef".
When one spells a compound declaration name in the source (e.g.,
insertSubview(_:aboveSubview:), keep track of the locations of the
base name, parentheses, and argument labels.
