C++ `operator bool()` is currently imported into Swift as `__convertToBool()`, which shouldn't be used by clients directly.
This adds a new protocol into the C++ stdlib overlay: `CxxConvertibleToBool`, along with an intitializer for `Swift.Bool` taking an instance of `CxxConvertibleToBool`.
rdar://115074954
Even though 'ClangDiagnosticConsumer' filters out 'clang::diag::err_module_not_found' from being emitted by the Swift compiler, delegating to Swift's module-loading logic for error-handling, we must also ensure that we reset Clang's 'DiagnosticEngine''s error count. Otherwise, if we do not, final stages of IRGen will query Clang's code-gen to finalize its 'Module', which Clang will not do if its internal DiagnosticEngine contains errors. This will cause Swift's IRGen to fail, even though the only error emitted was one Swift intended to suppress.
Wrap the `InheritedEntry` array available on both `ExtensionDecl` and
`TypeDecl` in a new `InheritedTypes` class. This class will provide shared
conveniences for working with inherited type clauses. NFC.
This change makes sure that `NSNotification.Name.NEVPNStatusDidChange` is imported correctly when C++ interop is enabled.
`importer::findSwiftNewtype` is called while writing Clang modules, at a point when the translation-unit scope does not exist (`clangSema.TUScope` is `nullptr`).
That prevents the Clang lookup from discovering `NSNotificationName` declaration.
Instead of trying to pass a translation-unit scope to Clang, let's use qualified name lookup which does not require a scope.
rdar://112199372
Lookup for custom reference counting operators into a precompiled bridging
header was causing a crash because there is no "underlying module" in which
to perform the lookup. Handle the lookup at the level of the main Swift
module for such cases, filtering out declarations not coming from Clang.
Fixes rdar://114495840.
This adds an `std.apinotes` file that is installed into `lib/swift/apinotes` along with existing Darwin apinotes. This new file is installed on all platforms. It replaces a few special cases in the compiler for `cmath` and `cstring` functions.
This does not require the upcoming APINotes support for namespaces, however, this does require https://github.com/apple/llvm-project/pull/7309.
rdar://107572302
The `incremental-extensions` is used for incremental parsing in the REPL
(which also changes how parsing runs). We only want "incremental
processing" in so far as it doesn't teardown the lexer or run the end of
translation unit action. This was joined into `incremental-extensions`,
but is now split apart again.
Resolves rdar://113406310.
This changes the heuristic that we use to detect `CF_OPTIONS`/`NS_OPTIONS` instantiations in C++ language mode.
Since libraries sometimes declare custom option types that break the assumptions about the names of such types, this lifts the requirements on the type name.
rdar://113524090
rdar://113279214
The existing synthesis mechanism had a bug: `cxxRecordDecl->hasDefaultConstructor()` returns true for C++ types with an implicit default constructor, for instance, `pthread_mutexattr_t`.
rdar://113708880
This will be used to provide a safe overload of `std::vector::erase` in Swift.
`std::vector::erase` is not currently imported into Swift because it returns a C++ iterator.
rdar://113704853
Instead of the code querying the compiler's built-in Clang instance, refactor the
dependency scanner to explicitly keep track of module output path. It is still
set according to '-module-cache-path' as it has been prior to this change, but
now the scanner can use a different module cache for scanning PCMs, as specified
with '-clang-scanner-module-cache-path', without affecting module output path.
Resolves rdar://113222853
Clang dependency scanning produces scanner PCMs which we may want to live in a
different filesystem location than the main build module cache.
Resolves rdar://113222853
This fixes a compiler error when building SwiftCompilerSources in hosttools mode with a recent Xcode.
```
<unknown>:0: error: calling a private constructor of class 'clang::StmtIterator'
swift/llvm-project/clang/include/clang/AST/StmtIterator.h:137:3: note: declared private here
StmtIterator(const StmtIteratorBase &RHS)
^
```
rdar://113514872
This makes it possible to initialize `std::vector` from a Swift Sequence. This also conforms C++ vectors to `ExpressibleByArrayLiteral`, making it possible, for instance, to pass a Swift array to a C++ function that takes a vector of strings as a parameter.
rdar://104826995