It is not completely uncommon for a record to get imported while
importing it's members (for example, if the member points back to the
parent record). In this case, simply use the already-imported record.
This should improve performance but also prevent an error where a member
accidentally had two parents.
This patch also moves around some of the member import/add logic to
allow for the above "optimization."
Our name lookup rules for the resolution of custom attributes don't
allow for them to find MainActor within the _Concurrency library.
Therefore, hardcode @MainActor to map to _Concurrency.MainActor.
While here, make sure we drop concurrency-specific attributes that
show up in Clang attributes when we aren't in concurrency mode.
If a static variable can be evaluated at compile time, create an
accessor using that value. This means static variables will always be
inlined and removed.
Note: currently this only works with numeric types.
The Clang swift_attr attribute allows C code to describe, via a Clang
attribute, the Swift attributes that should be applied to the given
declaration. When an
__attribute__((__swift_attr__("@tribute")))
occurs on a Clang declaration, parse the attribute within the string
literal as a Swift attribute, then attach that to the imported Swift
declaration.
Fixes rdar://70146633.
We already fixed this for "global" functions. This is a more generic
solution that works for "nested" functions as well. (Members or
functions in a namespace.)
When mirroring declarations from protocols, make sure to mirror for
all potential imported names. Otherwise, we might miss out on one or
the other of an async import or a completion-handler import of the
same method.
Fixes rdar://71429577.
This prevents an assertion in "isOverAligned" caused class templates
that contain and use typedefs.
Re-landing 7f2b0aad2b after being reverted
in 5ef0136356.
When importing Clang types.
This is not an option with Explicit Module Builds. If the module being built does not (directly or transitively) depend on `Foundation`, then attempting to load it will produce an error because Implicit module loading is no longer allowed..
This change addresses a small number of cases where ClangImporter relies on being able to load `Foundation` on-demand:
- When importing a single Decl from a clang module, we check whether it has certain conformances by checking all extensions of the NominalTypeDecl of the Decl in question, to see if any of the extensions contain the conformance we are looking for, but we only check extensions whose parent module is either the original module of the NominalTypeDecl or the overlay module of the NominalTypeDecl or Foundation. It seems that we do not need to actually import `Foundation` here, just checking the module Identifier should be sufficient.
- In `maybeImportNSErrorOutParameter`, change the behavior to have an exit condition based on whether `Foundation` can be imported, before attempting to load it.
- When checking whether or not we are allowed to bridge an Objective-C type, it also looks sufficient the query whether or not `Foundation` *can* be imported, without loading it.
Before this patch we would crash when importing a fully specialized
class template contianing a child declaration. This patch simply bails
on fully-specialized class templates instead of potentially crashing.
This is a small fix to prevent a crash. This change simply adds another
condition for the "bool" branch that checks if "type" is associated with
a "clang::EnumDecl" with an underlying type of "bool", and if so, treats
"type" as a "Bool".
The Microsoft extension permits the creation of structures without a
name which effectively create an anonymous inline structure. Accommodate
that in the ClangImporter.
For more details about the extension, see:
https://docs.microsoft.com/en-us/previous-versions/a3bbz53t(v=vs.140)#anonymous-structs
Thanks to @brentdax for the suggestion of the additional check!
