Previously, the lazily-created extensions used for globals imported as members of a type used the lazy module loader, but `ClangImporter::Implementation::loadNamedMembers()` didn’t actually work for them. Other parts of the compiler instead contrived to avoid loading these members by name by forcing all members to load before any selective loading might occur.
This commit modifies that code path to accommodate extensions with no matching clang node, which is how these are represented. With this change, other parts of the compiler can unconditionally use the `LazyMemberLoader` whenever it is present.
There may be performance improvements from this change, but I don’t expect any functional changes.
Prior to emission of `.d` and `.swiftdeps` outputs. In implicit builds such dependencies are registered during the construction of the corresponding Clang module by the ClangImporter's built-in Compiler Instance. In explicit builds, since we load pre-built PCMs directly, we do not get to do so. So instead, manually register all `.h` inputs of Clang module dependnecies.
Resolves rdar://121354886
It should be the responsibility of callers to map the type to a
contextual type, as needed. When it's not possible or repetitive to do
so, there is a special-purpose function `isInterfaceTypeNoncopyable` for
Sema.
"-opaque-pointers" has not been a valid clang cc1 argument for a long time
since it is the default. What is even worst is that clang is treating
that out of date option as "-o paque-pointers" and return no error.
Fortunately, ClangImport doesn't write anything to output file,
otherwise it is going directly to this "paque-pointers" file.
Previously, canImport lookup is not completely working with explicit
module due to two issues:
* For clang modules, canImport check still do a full modulemap lookup
which is repeated work from scanner. For caching builds, this lookup
cannot be performed because all modulemap and search path are dropped
after scanning.
* For swift module, if the canImport module was never actually imported
later, this canImport check will fail during the actual compilation,
causing different dependencies in the actual compilation.
To fix the problem, first unified the lookup method for clang and swift
module, which will only lookup the module dependencies reported by
scanner to determine if `canImport` succeed or not. Secondly, add all
the successful `canImport` check modules into the dependency of the
current module so this information can be used during actual
compilation.
Note the behavior change here is that if a module is only checked in
`canImport` but never imported still needs to be built. Comparing to
implicit module build, this can bring in additional clang modules if
they are only check inside `canImport` but should not increase work for
swift modules (where binary module needs to be on disk anyway) or the
most common usecase for `canImport` which is to check the same module
before importing.
rdar://121082031
In libstdc++ 11, `std::pair` has a base class `std::__pair_base`, which defines a copy constructor.
We still continue not treating `std::pair` as an owned type, just like on other platforms.
This allows calling a C++ function with default arguments from Swift without having to explicitly specify the values of all arguments.
rdar://103975014
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.
