ClangImporter’s SwiftLookupTables map Swift names to their corresponding Clang declarations. These tables are built into a module’s clang .pcm file and missing or inaccurate entries can cause name lookup to fail to find an imported declaration.
Swift has always included a helper function that would dump these tables, and swift-ide-test has a command-line switch that would invoke it, but these tools are clumsy to use in many debugging scenarios. Add a frontend flag that dumps the tables at the end of the frontend job, making it a lot easier to get at this information in the context of a specific compilation.
This fixes a compiler error that occurred while building `CxxStdlib.swiftmodule` and other projects that use C++ interop: `error: cannot find type 'std' in scope`.
The compiler was creating two distinct `swift::ModuleDecl` instances for the CxxStdlib module while building the CxxStdlib overlay: one as a main module (the module that is currently being compiled), one as a dependency of the main module. This confused the Swift name lookup logic down the road.
This only happened with recent libc++.
See the inline comment for more details.
rdar://122815523
An @_objcImpl extension with no category name *should* implement not only the class’s main @interface, but also any class extension @interfaces. Start making this true by making ObjCInterfaceAndImplementationRequest return all of these decls as the interfaces for such an implementation.
This commit doesn’t actually change Sema or IRGen to process the extra interfaces, so it’s NFC.
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
