Clang recently started wrapping more types in `clang::ElaboratedType` after this change: https://reviews.llvm.org/D112374
This broke some assumptions in ClangImporter, specifically in enum handling logic. This change adjusts those.
Fixes these tests in rebranch:
* `Interop/Cxx/enum/anonymous-with-swift-name-module-interface.swift`
* `Interop/Cxx/enum/anonymous-with-swift-name-objc-module-interface.swift`
* `Interop/Cxx/enum/anonymous-with-swift-name.swift`
* `Interop/Cxx/enum/c-enums-NS_OPTIONS-NS_REFINED_FOR_SWIFT.swift`
* `Interop/Cxx/enum/c-enums-NS_OPTIONS.swift`
* `Interop/Cxx/enum/c-enums-withOptions-omit.swift`
* `Interop/Cxx/class/inheritance/fields-module-interface.swift`
* `Interop/Cxx/class/inheritance/fields.swift`
* `Interop/Cxx/class/inheritance/functions-module-interface.swift`
* `Interop/Cxx/class/inheritance/sub-types-module-interface.swift`
* `Interop/Cxx/class/inheritance/type-aliases-module-interface.swift`
`getValue` -> `value`
`getValueOr` -> `value_or`
`hasValue` -> `has_value`
`map` -> `transform`
The old API will be deprecated in the rebranch.
To avoid merge conflicts, use the new API already in the main branch.
rdar://102362022
Introduce a new source file kind to describe source files for macro
expansions, and include the macro expression that they expand. This
establishes a "parent" relationship
Also track every kind of auxiliary source file---whether for macro
expansions or other reasons---that is introduced into a module, adding
an operation that allows us to find the source file that contains a
given source location.
Take the spellings for the attributes as parameters for the diagnostics
to allow us to reference the ignored the attribute properly. Use direct
pointer checks instead of an unnecessary `llvm::Optional` around a
nullable pointer. Use `llvm::StringRef` to simplify the comparison.
This avoids re-spelling the attribute parameters which have already been
checked by `isMutabilityAttr` for the contradiction.
This fixes an error that occurred when trying to use the subscript on an instance `std::map`:
```
error: cannot assign through subscript: 'map' is immutable
```
This was happening even with a mutable `std::map` instance.
`std::map::operator[]` has two overloads:
* `T& operator[]( const Key& key )`
* `T& operator[]( Key&& key )`
The second one is imported with an `inout` parameter, and we picked it as an implementation of the subscript getter because it was the last of the two overloads to get imported.
Swift does not allow subscripts with `inout` parameters. This is checked at the AST level, and those checks do not run for synthesized Swift code. This caused Swift to produce a surprising error which actually indicated that the argument of the subscript, not the instance itself, must be mutable.
rdar://100529571
Our current implementation of `func successor() -> MyType` relies on the ability to create a new instance of the type. For immortal foreign reference types, this wouldn't be reasonable to do.
rdar://100050151
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
