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.
- Adapt tests to changes that have happened in the meantime (e.g.
`HasVirtualBase` is rightly no longer considered loadable)
- Don't import copy or move constructors (noticed this because
references are now imported correctly, so copy and move constructors
suddenly started showing up in the SIL test)
- Don't try to define an implicitly-deleted default constructor (this
previously broke loadable-types-silgen.swift)
This reverts commit 29650d8c1f302708a32304d49c703c9ddbf30b75.
As discussed here, we want to import all constructors (whether they are
marked `noexcept` or not) as non-throwing initializers;
https://forums.swift.org/t/handling-c-exceptions/34823/50
Because C++ constructors always take a `this` pointer to the object to
be initialized, we mark the SIL function return type with the `@out`
attribute.
On the IRGen side, we retrofit support for formal indirect return values as
well as thin metatypes.
Infer @asyncHandler on a protocol methods that follow the delegate
convention of reporting that something happened via a "did" method, so
long as they also meet the constraints for an @asyncHandler method in
Swift. This enables inference of @asyncHandler for witnesses of these
methods.
We'll need this to get the right 'selfDC' when name lookup
finds a 'self' declaration in a capture list, eg
class C {
func bar() {}
func foo() {
_ = { [self] in bar() }
}
}
Allow the declaration of @objc async methods, mapping them to a
completion-handler API in Objective-C. This covers most of the
checking and semantics within the type checker:
* Declaring @objc async methods and checking their parameter/result types
* Determining the default Objective-C selector by adding
completionHandler/WithCompletionHandler as appropriate
* Determining the type of the completion handler parameter
* Inferring @objc from protocol requirements
* Inferring @objc from an overridden method
When a given Objective-C method has a completion handler parameter
with an appropriate signature, import that Objective-C method as
async. For example, consider the following CloudKit API:
- (void)fetchShareParticipantWithUserRecordID:(CKRecordID
*)userRecordID
completionHandler:(void (^)(CKShareParticipant * _Nullable shareParticipant, NSError * _Nullable error))completionHandler;
With the experimental concurrency model, this would import as:
func fetchShareParticipant(withUserRecordID userRecordID: CKRecord.ID) async throws -> CKShare.Participant?
The compiler will be responsible for turning the caller's continuation
into a block to pass along to the completion handler. When the error
parameter of the completion handler is non-null, the async call
will result in that error being thrown. Otherwise, the other arguments
passed to that completion handler will be returned as the result of
the async call.
async versions of methods are imported alongside their
completion-handler versions, to maintain source compatibility with
existing code that provides a completion handler.
Note that this only covers the Clang importer portion of this task.
This is a roll-forward of https://github.com/apple/swift/pull/32950, with explicit c++17 version removed from tests. This is not needed since C++17 is the default anyway.
--
In this PR we teach `ClangImporter` to import typedef statements with template instantiation as its underlying type.
```c++
template<class T>
struct MagicWrapper {
T t;
};
struct MagicNumber {};
typedef MagicWrapper<MagicNumber> WrappedMagicNumber;
```
will be made available in Swift as if `WrappedMagicNumber` is a regular struct.
In C++, multiple distinct typedeffed instantiations resolve to the same canonical type. We implement this by creating a hidden intermediate struct that typedef aliasses.
The struct is named as `__CxxTemplateInst` plus Itanium mangled type of the instantiation. For the example above the name of the hidden struct is `__CxxTemplateInst12MagicWrapperI11MagicNumberE`. Double underscore (denoting a reserved C++ identifier) is used to discourage direct usage. We chose Itanium mangling scheme because it produces valid Swift identifiers and covers all C++ edge cases.
Imported module interface of the example above:
```swift
struct __CxxTemplateInst12MagicWrapperI11MagicNumberE {
var t: MagicNumber
}
struct MagicNumber {}
typealias WrappedMagicNumber = __CxxTemplateInst12MagicWrapperI11MagicNumberE
```
We modified the `SwiftLookupTable` logic to show hidden structs in `swift_ide_test` for convenience.
Co-authored-by: Rosica Dejanovska <rosica@google.com>
Co-authored-by: Dmitri Gribenko <gribozavr@gmail.com>
Co-authored-by: Robert Widmann <devteam.codafi@gmail.com>
