Redirecting file system can canonicalize the file path before forwarding
the path to IncludeTreeFileSystem, which is a simplied FS that can only
intepret the paths that has been seen by dep-scanner. Since all files
that need redirecting already added to underlying FS via DepScan, there
is no need for such layer when compiling using clang-include-tree.
rdar://119727344
When caching + clang include tree is enabled, don't take module map file
from command-line in clang importer. Those are resulted from `-Xcc`
arguments and do not needed in compilation since module maps are
included in include-tree.
rdar://119577349
Re-write and clean up how clang-importer is created from clang
arguments. Previously, it is unclear if `getClangArguments` will return
CC1 args or driver args and the logic is unnecessarily compilicated when
creating clang invocation. Now clang invocation is always created from
cc1 arguments, which can be directly provided via direct-cc1-mode or
converted from driver args.
There is no functional changes in this patch, other than
`-dump-clang-diagnostics` now will always print cc1 args, and also
driver args if that is applicable.
libc++ recently split the `std` module into many top-level modules: 571178a21a
Previously if a C++ module had `#include <iosfwd>`, importing that module in Swift would make the entire C++ stdlib visible from Swift, since it was a single top-level Clang module. After libc++ got split it doesn't automatically do so, but we need to preserve the current behavior for Swift users.
rdar://119270491
This commit diagnoses cdecl implementations with no matching imported declaration, and also runs them through the ObjCImplementationChecker. Actually testing that the ObjCImplementationChecker diagnoses various failure conditions correctly will be added in a subsequent commit.
libc++ recently split the `std` module into many top-level modules: 571178a21a
This prevented the conformances to `CxxSet`, `CxxVector`, etc. from being synthesized with a fresh libc++ version.
rdar://119270491
Swift names provided via C attributes or API notes can be parsed as
special names, such as `init` or `subscript`. However, doing so would
cause the Clang importer to crash, because it assumes that these names
are always identifiers. In these places, we actually want to treat
them as identifiers, where special names are mapped back to their
keywords. Introduce a function to do that, and use it consistently.
These two requests are effectively doing the same thing to two
different cases within CatchNode. Unify the requests into a single
request, ExplicitCaughtTypeRequest, which operates on a CatchNode.
This also moves the logic for closures with explicitly-specified throws
clauses into the same request, taking it out of the constraint system.
Swift has some module maps it overlays on Linux and Windows that groups all of the C standard library headers into a single module. This doesn’t allow clang and C++ headers to layer properly with the OS/SDK modules. clang will set -fbuiltin-headers-in-system-modules as necessary for Apple SDKs, but Swift will need to pass that flag itself when required by its module maps.
The spelling kind was only ever set to
`StaticSpellingKind::None`, and the static location
was never used for anything (and should be queried
on the storage anyway). This doesn't affect the
computation of `isStatic` since `IsStaticRequest`
already takes the static-ness from the storage for
accessors.
This removes a special case in the compiler for these types, and applies the `import_owned` attribute to all instantiations of `vector` and `basic_string` via API Notes.
This is a simple work around to avoid importing virtual functions when symbolic
imports are turned on. Test cases that were failing before this WA are in
test/Interop/Cxx/symbolic-imports.
Thanks to Alex Lorenz for providing this WA to me (@hyp).
This is a forward-interop feature that wires up existing functionality for
synthesizing base class function calling to enable virtual function calling.
The general idea is to sythesize the pattern:
```
// C++ class:
struct S { virtual auto f() -> int { return 42; } };
// Swift User:
var s = S()
print("42: \(s.f())")
// Synthetized Swift Code:
extension S { func f() -> CInt { __synthesizedVirtualCall_f() } }
// Synthetized C/C++ Code:
auto __cxxVirtualCall_f(S *s) -> int { return s->f(); }
```
The idea here is to allow for the synthetized C++ bits from the Clang side to
handle the complexity of virtual function calling.
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.
