Swift was previously crashing while emitting an error ("could not generate C++ types from the generic Swift types provided") for C++ decls that do not have a name, such as constructors: `func->getName()` triggered an assertion.
Trying to use members of C++ private base classes from Swift causes an assertion failure in ClangImporter:
```
<build dir>/swift/lib/swift/macosx/arm64/libcxxshim.h:2:66: error: cannot cast 'A' to its private base class 'B'
To __swift_interopStaticCast(From from) { return static_cast<To>(from); }
^
```
Such members should not be exposed.
rdar://103871000
C++ iterator types are often templated, and sometimes declare `operator==` as a non-member templated function. In libc++, an example of this is `__wrap_iter` which is used as an iterator type for `std::vector` and `std::string`.
We don't currently import templated non-member operators into Swift, however, we still want to support common C++ iterator patterns.
This change adds logic to instantiate templated non-member `operator==` for types that define `iterator_category` and are therefore likely to be valid iterator types.
rdar://97915515
If a templated C++ class declares an operator as a member function, and is instantiated using a typedef or a using-decl on the C++ side, it previously could not be conformed to a Swift protocol that requires the operator function despite matching signatures.
This was due to a Swift name lookup issue: operators, unlike regular member functions, are found by doing an unqualified lookup. Since C++ class template specializations and their members are not added to `SwiftLookupTable`, when doing qualified lookup members are searched by looking at all of the members of the specialization and choosing the ones with matching names. With unqualified lookup, we cannot rely on knowing the right specialization and need to search for all the operators in a given module.
This change adds synthesized operator thunks to `SwiftLookupTable` to make them discoverable by unqualified lookup.
`ClangImporter::Implementation::lookupValue` used to return `false` if it found an overloaded C++ operator that is declared as a member function of a C++ type.
This doesn't have any effect now since the return value isn't used under normal conditions, but it might bite us later.
If an operator is declared as a method of a templated class, we were failing to look it up during auto-conformance to `UnsafeCxxInputIterator`.
This fixes `Interop/Cxx/stdlib/use-std-map.swift` on Ubuntu.
rdar://102420290
`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
This lifts the requirement for the user to explicitly add `import Cxx` in Swift code that relies on protocols from the `Cxx` module, such as `CxxSequence`.
Stored properties are only allowed in the extension implementing the class's main interface, not its categories. This also means banning `@objc final`, which is unenforceable anyway when ObjC subclasses are allowed, and therefore allowing `@objc let` and `@objc static` properties to be overridden if they're declared in objcImplementations.
Controlled with a new flag '-direct-clang-cc1-module-build'
This will allow clients to formulate 'swift-frontend' invocations with fully-specified set of cc1 arguments (using '-Xcc -Xclang -Xcc <FLAG>') required for the PCM build, without having to go through the driver.
`e3c58386` introduced an ASAN error:
```
ERROR: AddressSanitizer: stack-use-after-scope on address ...
in swift::ClangImporter::Implementation::loadModuleClang ...
SUMMARY: AddressSanitizer: stack-use-after-scope ClangImporter.cpp:1903 in swift::ClangImporter::Implementation::loadModuleClang
```
rdar://99986478
C++ standard library module is called `std`. To make it more clear to a Swift developer that this module is a C++ stdlib, and not a Swift stdlib, let's rename it to `CxxStdlib`.
This is the first step in the module rename. We don't ban `std` in this patch to be able to build SwiftCompilerSources with hosttools until a new Swift compiler is shipped.
Basic should not be allowed to link Parse, yet it was doing so
to allow Version to provide a constructor that would conveniently
parse a StringRef. This entrypoint also emitted diagnostics, so it
pulled in libAST.
Sink the version parser entrypoint down into Parse where it belongs
and point all the clients to the right place.
Previously, when evaluating a `#if canImport(Module, _version: 42)` directive the compiler could diagnose and ignore the directive under the following conditions:
- The associated binary module is corrupt/bogus.
- The .tbd for an underlying Clang module is missing a current-version field.
This behavior is surprising when there is a valid `.swiftinterface` available and it only becomes apparent when building against an SDK with an old enough version of the module that the version in the `.swiftinterface` is too low, making this failure easy to miss. Some modules have different versioning systems for their Swift and Clang modules and it can also be intentional for a distributed binary `.swiftmodule` to contain bogus data (to force the compiler to recompile the `.swiftinterface`) so we need to handle both of these cases gracefully and predictably.
Now the compiler will enumerate all module loaders, ask each of them to attempt to parse the module version and then consistently use the parsed version from a single source. The `.swiftinterface` is preferred if present, then the binary module if present, and then finally the `.tbd`. The `.tbd` is still always used exclusively for the `_underlyingVersion` variant of `canImport()`.
Resolves rdar://88723492
Before this patch we tried to do lookup in the _ObjC module for the retain/release functions. Now we use the clang module that the reference type lives in.
The logic is here for this in the importer, which means the module interface tests make it appear that the behavior is correct, but lazy member lookup still finds the constructors, so this patch fixes that part.
This fixes an assertion that tripped when running `member-inline.swift` test with an unrelated patch:
```
type is not an l-value in LHS of assignment: Int32
...
3. While walking into body of setter for subscript(_:) (in module 'MemberInline')
```
