If a C++ type `Derived` inherits from `Base` privately, the public methods from `Base` should not be callable on an instance of `Derived`. However, C++ supports exposing such methods via a using declaration: `using MyPrivateBase::myPublicMethod;`.
MSVC started using this feature for `std::optional` which means Swift doesn't correctly import `var pointee: Pointee` for instantiations of `std::optional` on Windows. This prevents the automatic conformance to `CxxOptional` from being synthesized.
rdar://114282353 / resolves https://github.com/apple/swift/issues/68068
We do not synthesize the inheritance thunks correctly for such methods. Do not try to synthesize them, as that causes issues when there are two overloads of the same method, one with rvalue this and one without.
The proper solution is tracked as https://github.com/apple/swift/issues/69745
Unblocks rdar://114282353
If a PCH was output with errors, it may not have serialized all its
inputs. If there was a change to the search path or a headermap now
exists where it didn't previously, it's possible those inputs will now
be found. Ideally we would only rebuild in this particular case rather
than any error in general, but explicit module builds are the real
solution there. For now, just treat PCH with errors as out of date.
Resolves rdar://117037471.
For any operation that can throw an error, such as calls, property
accesses, and non-exhaustive do..catch statements, record the thrown
error type along with the conversion from that thrown error to the
error type expected in context, as appropriate. This will prevent
later stages from having to re-compute the conversion sequences.
Conflicts:
- `lib/AST/TypeCheckRequests.cpp` renamed `isMoveOnly` which requires
a static_cast on rebranch because `Optional` is now a `std::optional`.
Parse typed throw specifiers as `throws(X)` in every place where there
are effects specified, and record the resulting thrown error type in
the AST except the type system. This includes:
* `FunctionTypeRepr`, for the parsed representation of types
* `AbstractFunctionDecl`, for various function-like declarations
* `ClosureExpr`, for closures
* `ArrowExpr`, for parsing of types within expression context
This also introduces some serialization logic for the thrown error
type of function-like declarations, along with an API to extract the
thrown interface type from one of those declarations, although right
now it will either be `Error` or empty.
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.
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.
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.
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 is a futile attempt to discourage future use of getType() by
giving it a "scary" name.
We want people to use getInterfaceType() like with the other decl kinds.
`IncrementalProcessing` is now a language option
`IncrementalExtensions`, which also means it is now part of the module
hash.
When compiling a clang module, the output file path would be generated
in the `BeginSourceFile` prior to `enableIncrementalProcessing` being
called on the preprocessor. The hash would then be generated again when
compiling the module (after the `enableIncrementalProcessing` call) and
included in the PCM, leading to a mismatch between the path and the hash
in the module.
This could be fixed by moving `enableIncrementalProcessing` above
`BeginSourceFile`, but now that it's an option we can instead just add
it to the invocation arguments.
Resolves rdar://112993659.
This prevented `std::vector<std::string>` from being auto-conformed to `CxxRandomAccessCollection`.
If an iterator type is templated, and does not have an explicit instantiation via a typedef or a using-decl, its specialization will not have an owning Clang module. Make sure we treat it as a part of the Clang module that owns the template decl.
rdar://112762768 / resolves https://github.com/apple/swift/issues/67410
