Calling `StructDecl::lookupDirect` with an operator identifier (e.g. `==`) previously returned no results. This happened because the underlying C++ operator function was added to the lookup table with an underscored name (e.g. `__operatorEqualEqual`), and the synthesized function was not added to the lookup table at all. Lookup should find the synthesized decl, since that is what Swift code will call.
This fixes a typechecker error when trying to conform a C++ struct that defines an operator to a Swift protocol with an operator requirement (e.g. `Equatable`).
* Update ImportDecl to handle Friend functions inside of recrods
* Add tests and update comment
* Undo unnecessary lines, format
* Clean up and fix tests
* New approach
* Only import valid friend functions for now
* Re-add == func to get Equatable conformance
* Remove requirement that friend is a function
This reduces the specialization limit from 10000 to 1000 to prevent Swift from failing to import libstdc++ due to `std::_Index_tuple` being defined recursively.
This also adds a diagnostic to let the user know why a template instantiation wasn't imported.
rdar://96324175
We saw a test case failing when 2 records contain the same operator. This occurs because when the first operator is called, we import the record associated with that operator but we also import the _function_ for the 2nd record. So if we have 2 records `Foo` and `Bar` and both implement `operator-`, after calling `Foo`'s `operator-` we would have imported
1. `Foo`
2. `Foo.operator-`
3. `Bar.operator-`
Then when we call `Bar.operator-` we try importing `Bar` record & then import the operator again. So that ends up with
1. `Foo`
2. `Foo.operator-`
3. `Bar.operator-`
4. `Bar`
5. `Bar.operator-`
which causes there to be 2 imports of the same operator (`FuncDecl`)
This patch checks to see if the `FuncDecl` was previously imported and returns early if it has been
Thanks @egorzhdan and @zoecarver for helping me debug this one :p
C++ pre-increment operator `T& T::operator++()` is mapped into a non-mutating function `successor() -> Self`.
The naming matches existing functions for `UnsafePointer`/`UnsafeMutablePointer`.
The purpose of this is to be used for iterator bridging: C++ requires iterators to define a pre-increment operator (https://en.cppreference.com/w/cpp/named_req/Iterator), which Swift will use to iterate over C++ sequences and collections.
`ImportDecl.cpp` contained 10k+ lines of code, which caused slowdowns in incremental compilation and while editing the code in the IDE.
This change extracts a chunk of largely self-contained decl synthesis logic into a separate file.
C++ iterator dereference operator is mapped to a Swift computed property called `pointee`.
For example:
```cpp
struct ConstIterator {
// ...
const int &operator*() const { /* ... */ }
};
```
is imported as
```swift
struct ConstIterator {
var pointee: Int32 { get }
@available(*, unavailable, message: "use .pointee property")
func __operatorStar() -> UnsafePointer<Int32>
}
```
In C++-Interop mode some of the Foundation @availables were not getting
their "renamed:" attributes filled in and this was because of the
LookupName issue as we have seen before where LookupName bails in C++
mode due to a nullptr scope resulting in something not getting imported
completely.
This patch merely passes a TUscope to avert this.
I believe ignoring the existing enum issues this should bring
Foundation with C++-Interop to parity with ObjC-Interop.
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>
