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.
This is required to make the compiler distinguish between instantiations of `std::function`.
Previously, when generating a Swift type name for a `std::function` instantiation, we would always emit `_` as the template parameter. If someone referenced two different instantiations of `std::function` in a Swift module, they would get mangled with the same name, triggering linker errors later.
rdar://103979602
Under a set of circumstances that I cannot fully characterize, it was possible for `ClangImporter::Implementation::importDeclContextOf()` to end up recursing until stack overflow while trying to import a global as a member.
The cycle was caused by `addExtension()` using a newly-created extension’s lazy member loader to load its members before the extension had been added to ClangImporter’s `extensionPoints` table. Loading the members would try to import the IAM members again, which would cause `importDeclContextOf()` to try to create another extension to contain them, which `addExtension()` would force to load those members. Repeat until stack overflow.
I have fixed this bug by registering the extension in the `extensionPoints` map before its member loader is set. This ensures that if `importDeclContextOf()` gets called for any reason after that point, it will return the existing extension instead of creating a new one, avoiding the cycle.
Unfortunately, I was not able to figure out the exact conditions that were necessary to reproduce this bug, so I have not included a test. However, I have tested with the affected project locally and confirmed that this change lets it build. All existing tests pass.
Fixes rdar://120854030.
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.
Support for `swift_attr` has been extended to type contexts.
Such attributes form `clang::AtributedType` that carries an
optional `clang::Attr *`. Teach `importType` has to examine
immediate sugar to determine whether it carries any concurrency
information and, if so, add it to `ImportTypeAttrs` to be
applied after import.
`clangSema.isCompleteType` checks for decl visibility according to the module visibility rules, which we don't actually need. What we need to check is whether the record has a definition – this is the check we already use elsewhere in ClangImporter.
This makes sure that we can import `std::function` on Windows.
rdar://103979602
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
Currently, `-direct-clang-cc1-module-build` and `-only-use-extra-clang-opts`
have to be passed together for clang importer creation to succeed.
Missing either will result in error. Simplified the swift-frontend flags
by removing `-only-use-extra-clang-opts` and let
`-direct-clang-cc1-module-build` to do both.
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.
Clang rejects code that tries to call a constructor of an abstract C++ class with an error: "Variable type 'Base' is an abstract class". Swift should reject this as well.
rdar://119689243
libc++ recently split the `std` module into many top-level modules: 571178a21a
This broke the logic that conforms C++ iterator types to `UnsafeCxxInputIterator`/`UnsafeCxxRandomAccessIterator`. To determine if a C++ type is an iterator type, we look for its inner type called `iterator_category`. After module std was split, Clang instantiates `std::string::const_iterator::iterator_category` twice and doing a Clang lookup within the `const_iterator` type returns two identical `TypedefDecl`s. Clang itself has logic to merge them, but Swift doesn't.
rdar://119270491
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
