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!
Previously, when we checked for `!hasUserDeclaredConstructor` rather than
`isAggregate`, we would always generate memberwise initializers for C
record types. This updates the isAggregate to be true for non-C++ types
so we will generate memberwise initializers for them as well.
* Check isAggregate instead of hasUserDeclaredConstructor.
* Rename addEmptyArgNamesForCxxFunc -> addEmptyArgNamesForClangFunction.
* Other minor fixes and cleanups.
* Update tests that relied on old behavior.
* Use mangleCXXName instead of mangleCXXCtor.
* Call VisitCXXRecordDecl not VisitRecordDecl from
VisitClassTemplateSpecializationDecl. This allows template constructors
to be imported and called correctly.
