This removes a longstanding workaround in the import logic for C++ structs:
Swift assumed that if a C++ struct has no copy constructor that is explicitly deleted, then the struct is copyable. This is not actually correct. This replaces the workaround with a proper check for the presence of a C++ copy constructor.
rdar://136838485
The Clang importer maps arbitrary attributes spelled with `swift_attr("...")`
over to Swift attributes, using the Swift parser to process those attributes.
Extend this mechanism to allow `swift_attr` to refer to an attached macro,
expanding that macro as needed.
When a macro is applied to an imported declaration, that declaration is
pretty-printed (from the C++ AST) to provide to the macro implementation.
There are a few games we need to place to resolve the macro, and a few more
to lazily perform pretty-printing and adjust source locations to get the
right information to the macro, but this demonstrates that we could
take this path.
As an example, we use this mechanism to add an `async` version of a C
function that delivers its result via completion handler, using the
`@AddAsync` example macro implementation from the swift-syntax
repository.
We should still try adding the overlays, even if we're asked not to
generate a diagnostic while doing so. That's slightly safer because
it means that we're less likely to find ourselves in a situation
where `swift-modulewrap` wants to use types from the C/C++ library
and can't.
rdar://115918181
For now, this logic is used for importing fewer unannotated types as
unsafe. In the future, this logic will be used by escapability inference
for other (non-aggregate) types.
In this mode all C++ types are imported as unsafe by default. Users
explicitly marking types are escapable or not escapable can make them
imported as safe. In the future, we also want to import unannotated
functions as unsafe and add more logic to infer types that are actually
safe, like agregates of escapable types.
`swift-modulewrap` uses the `ClangImporter` to obtain a module loader,
but it doesn't take an SDK argument (nor does anything bother to pass
one), which means that when cross-compiling you get warnings about not
being able to find the C library.
Suppress the warning by telling the `ClangImporter` that we don't care
about the C library here.
rdar://115918181
This service on ModuleDecl wasn't actually used before this PR. The main
client in ASTPrinter calls direclty the underlying logic in FileUnit.
Let's update it for our needs.
Honour the SDK for APINotes to augment the system libraries. This allows
us to distribute APINotes with the Swift SDK and impact the system
without having to map the APINotes into the filesystem.
This makes it easier to experiment with noescapable types in interop.
Moreover, we always wanted to have this annotation for completeness,
similar to SWIFT_NONCOPYABLE.
Also, dump the module map paths when `-Xfrontend -dump-clang-diagnostics` is
passed in, both so we can check that manually and in these tests, and fix
another Frontend test to be more specific now that this other output trips it up.
Fix a bug that swift clang importer is not setup correctly when prefix
map is used. There are two separate issues:
* CC1 args used to setup clang import when building swift (interface and
sources) are not correctly remapped.
* When loading SDKInfo from SDK path, the SDKSettings.json is not
loading from VFS, thus the file cannot be loaded from remapped path.
rdar://134458611
This makes sure that Swift respects `-Xcc -stdlib=libc++` flags.
Clang already has existing logic to discover the system-wide libc++ installation on Linux. We rely on that logic here.
Importing a Swift module that was built with a different C++ stdlib is not supported and emits an error.
The Cxx module can be imported when compiling with any C++ stdlib. The synthesized conformances, e.g. to CxxRandomAccessCollection also work. However, CxxStdlib currently cannot be imported when compiling with libc++, since on Linux it refers to symbols from libstdc++ which have different mangled names in libc++.
rdar://118357548 / https://github.com/swiftlang/swift/issues/69825
Avoid constructing tasks with `-Xcc` options that references clang
CASOptions. This is going to make the cache hit/miss to be dependent on
CAS location/configuraitons.
Instead, only give swift CASOptions to constructed tasks and propagate
the configurations to underlying clang importer.
rdar://132255889
To better investigate reports of an infinite recursion in `hasPointerInSubobjects`, let's add a pretty stack trace entry to get more readable crash reports.
rdar://131366982
The decision to exclude `-Xcc -D` options from swift module hash
actually doesn't help to solve the problem. It wouldn't reduce the
module variants (or the number of swiftmodule build commands) because
the command-line also encodes all the clang PCM dependencies that do get
affected by `-Xcc` flags.
To avoid the false sharing and the nondeterministic build products,
include most of the `-Xcc` flags, except include search path, into swift
module hash.
rdar://132046247
Control enforcement of member import visibility requirements via a new option,
instead of piggy-backing on the existing IgnoreAccessControl option. Adopt the
option when doing fallback lookups for unviable members so that the compiler
can diagnose the reason that a member is inaccessible more reliably.
Previously, with MemberImportVisibility enabled decls with the package access
level could be mis-diagnosed as inaccessible due to their access level when
really they were inaccessible due to a missing import.
Resolves rdar://131501862.
