In C, one can provide a typedef name for an anonymous tag declaration in
one shot, e.g.,
typedef struct {
double x, y
} Point;
In this case, there are effectively two declarations at the C level:
the typedef and the struct. The Clang importer was only taking
attributes from the anonymous struct (i.e., the tag) and not from the
typedef. However, any attributes put before the `typedef` should apply
as well... so consider those, too.
For now, only do this for `swift_attr` attributes, because we're
seeing this primarily with `Sendable` annotations. In the future, we
can look to generalizing it, but that could have source-breaking
consequences.
Fixes rdar://91632960.
This does not include subscript operators.
Before this is re-enabled operators need to be re-implemented. Right now they are the source of a lot of bugs. They cause frequent crashes and mis compiles. Also, templated operators insert a lot of names into global lookup which causes problems.
They also don't work on Windows.
If `__attribute__((swift_attr(“@Sendable”)))` is applied to an ObjC method, ObjC property, C field, C variable, or C function, we will now make its result type `Sendable`.
For some entities, this technically had a different behavior previously, because `@Sendable` can be applied to `func`s to indicate that their interface type should be `@Sendable`. We don’t really want people to use this functionality on non-local functions, so we can safely remove it.
This isn’t quite interacting with `Unmanaged` the way we’d want, but I’ve included test cases for the current behavior with FIXME comments.
Fixes rdar://90491024.
`ClangImporter::Implementation::importType()` and associated parts of the importer are now passed an `llvm::function_ref` they can use to emit import diagnostics on the declaration they’re importing, and the `ImportDiagnosticAdder` helper class provides a convenient way to construct such a function.
This capability is not actually *used* in this commit—we are simply threading this function through the importer—so there is no change in behavior.
When using libc++, Swift imports `size_t` as Int despite `size_t` being an unsigned type. This is intentional & is specified in `lib/ClangImporter/MappedTypes.def`. Previously, MappedTypes were only honored for C/C++ types declared on the file level.
In libstdc++, `size_t` is declared within `namespace std` and not on the file level, so the mapping to Int was not applied.
This change ensures that MappedTypes are also applied to types declared in `namespace std`.
This prepares us to generalize ObjC selector collision diagnostics to also include protocols. NFC in this commit because, even though Sema and ClangImporter now try to record ObjC methods on non-`ClassDecl`s, `NominalTypeDecl::createObjCMethodLookup()` still doesn’t create ObjC method tables for them, so the calls are no-ops.
As per SR-14137 this caches entries in ImportedDecls even when the
import failed.
Also have to mention I did this based on Thomas's PR #36747.
This should help us better handle complex templates and dependant types.
* fixing setters
* adding tests
* Removing extras
* fixing tests
* Better naming for properties
* Cleanup
* Add tests
* Clang format it
* more refactoring and some more tests
* More tests and more fixes
* Updating tests:
fixing other tests to work with new property importing
* Fix the two asserts. Move things around. Remove createImported. Move CXXMethodBridging to it's own header.
* General updates:
Fixing tests, adding radars to follow issues that cna be a started issues on the project.
Also Factoring out MethodBridging.
* Fixing Comments left on the PR:
General formatting.
* Fixing tests, and general updates for formatting
* removing extras and passing this on swift.
Co-authored-by: Omar Habra <ohabra@apple.com>
This commit adds very basic support for importing and calling base class methods, getting and setting base class fields, and using types inside of base classes.
If a method has an `async` variant, the non-`async` variant will now mark its completion handler parameter `@Sendable`. This shouldn't be a breaking change in Swift 5 code since these declarations are automatically `@_predatesConcurrency`.
Also adds:
• Support for `@_nonSendable` on parameters, which can be used to override this implicit `@Sendable`
• Support for `@Sendable` on block typedefs; it's generally going to be a good idea to mark completion block typedefs `@Sendable`.
Fixes rdar://85569247.
When we switched this path over to use lazy member loading, a
subsequent commit introduced a check that members were canonical. In
certain extremely twisty scenarios involving multiple modular frameworks
pulling in non-modular headers, this check can fail which results in us
silently dropping these members on the floor.
It's ultimately correct to only pull in the canonical members, but real-world
examples of "system" frameworks evading modularity diagnostics exist so this
is strictly a regression.
Drop the canonicity check for FieldDecls.
rdar://86740970
There are three major changes here:
1. The addition of "SILFunctionTypeRepresentation::CXXMethod".
2. C++ methods are imported with their members *last*. Then the arguments are switched when emitting the IR for an application of the function.
3. Clang decls are now marked as foreign witnesses.
These are all steps towards being able to have C++ protocol conformance.
This patch introduces new diagnostics to the ClangImporter to help
explain why certain C, Objective-C or C++ declarations fail to import
into Swift. This patch includes new diagnostics for the following entities:
- C functions
- C struct fields
- Macros
- Objective-C properties
- Objective-C methods
In particular, notes are attached to indicate when any of the above
entities fail to import as a result of refering an incomplete (only
forward declared) type.
The new diangostics are hidden behind two new flags, -enable-experimental-clang-importer-diagnostics
and -enable-experimental-eager-clang-module-diagnostics. The first flag emits diagnostics lazily,
while the second eagerly imports all declarations visible from loaded Clang modules. The first
flag is intended for day to day swiftc use, the second for module linting or debugging the importer.
Back when we were eagerly importing struct fields, we only attempted to import fields under the names they have in the current version; previous versions and the raw name were ignored. Now that we're importing them lazily, we're passing through code that attempts to import all versions. That's a nice idea in theory, but neither ImportDecl nor the rest of the compiler was prepared for this, and so ImportDecl has started adding redundant stored properties to clang structs. This trips an assertion in IRGen.
This commit returns to the old behavior of only importing struct fields under their current name by simply early-exiting from SwiftDeclConverter::VisitFieldDecl(). We can come up with a solution that imports the variants in the future.
Fixes rdar://86069786.
Unlike normal Objective-C functions, Swift does not directly call
Objective-C constructors because it creates a thunk to allocate the
object and call then constructor dynamically. This can be fixed, but for
now emit a compile-time error rather than a runtime error.
In C/ObjC interop mode a Clang AST with an ObjC Category resembles:
TranslationUnitDecl
`-ObjCCategoryDecl
However in C++-Interop mode the same Category could potentially have an
extern "C" linkage specifier (guarded with #ifdef __cplusplus) and
resembles:
TranslationUnitDecl
|-LinkageSpecDecl
`-ObjCCategoryDecl
In the latter case when the ClangImporter attempts to import the
category in swift::ClangImporter::Implementation::importDeclContextOr,
prior to this patch, would bail because it is expecting the DeclContext
above the ObjCCategoryDecl to be a TranslationUnitDecl and when it isn't
it returns nullptr.
Because of this, of course the category does not get imported as a swift
extension and therefore any fields or methods are also not imported.
In the case of UIKit, UIView has one of these categories that are
extern-"C"'ed due to UIKIT_EXTERN containing the linkage specifier in
-enable-cxx-interop mode. Since UIView is inherited by lots of other
UIKit types (UILabel etc), many of these types also have lots of missing fields
as well.
This patch checks to see if the decl about to be imported in
importDeclContextOr has a linkage specifier as it's context and makes
sure to materialize the TU from the parent of the declcontext instead of
just immediately bailing. Because of this, this patch enables
c++-interop mode to compile code that uses UIKit without hitting this
mis-compile.
Loading of the members of a C(++) struct/class can occur while doing a
direct lookup, so triggering a second direct lookup inside there can
introduce a request-evaluator cycle. Reimplement this operation to be
more like the way we lazily populate Objective-C classes and protocols,
walking through the record members in order and importing their
variants, then adding those. This eliminates a bunch of extraneous
lookup work, keeps the members in order (see the test case change),
and eliminates the potential for cycles.
