This makes ClangImporter automatically conform C++ sequence types to `Cxx.CxxSequence` protocol.
We consider a C++ type to be a sequence type if it defines `begin()` & `end()` methods that return iterators of the same type which conforms to `UnsafeCxxInputIterator`.
Calling `clangSema.isCompleteType` tries to instantiate a template, and if that is impossible, returns `true`. This caused Swift to try to import invalid C++ template instantiations.
This was discovered during C++ interop adoption in SwiftCompilerSources:
Several LLVM headers declare a field with a type `DenseMap<int, ForwardDeclared>` where `ForwardDeclared` is defined in an implementation file (`.cpp`) and is not visible to ClangImporter. That is valid in C++ but caused an error when importing into Swift.
When ClangImporter calls Clang to import a module, Clang calls `SwiftLookupTableWriter::writeExtensionContents` for each namespace redecl, which called `addEntryToLookupTable` (a few frames omitted) which iterated over all of the namespace redecls, doing duplicate work. This caused the complexity to degrade from linear to quadratic.
`SwiftDeclConverter::VisitNamespaceDecl` is still called once per namespace, not per redecl, so we need to iterate over all the redecls there.
This dramatically improves the build time for SwiftCompilerSources when importing Clang headers in addition to LLVM headers.
C++ operator functions are `NamedDecl`s, but they don't have a trivial name, and calling `getName` results in an assertion failure.
This was discovered during C++ interop adoption in SwiftCompilerSources.
```
Assertion failed: (Name.isIdentifier() && "Name is not a simple identifier"), function getName, file Decl.h, line 277.
...
/Volumes/Projects/swift/llvm-project/clang/include/clang/AST/DependentDiagnostic.h:150:8: importing 'clang::DeclContext::ddiag_iterator::operator=='
```
This teaches ClangImporter to synthesize conformances of C++ iterator types to `UnsafeCxxInputIterator` protocol from the `Cxx` module.
We consider a C++ type to be an iterator if it defines a subtype (usually a typedef or a using decl) called `iterator_category` that inherits from `std::input_iterator_tag`.
rdar://96235368
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.
