Any safe wrapper expansion originating in a bridging header would fail
typechecking because the `__ObjC` module doesn't import the standard
implicit imports. This is because the main module is not available to
inherit implicit imports from when the `__ObjC` module is created. We
don't need all of the implicit modules for safe wrappers, so import
`Swift` specifically.
rdar://163078116
Inheriting a clang import marked `requires: !swift` will always result
in an error. This skips such imports, which *may* result in name lookup
errors instead, but also may not, depending on the module.
rdar://161795145
`span` is not available in all versions of libstd++, so make it a
conditional header. Also adds other missing c++20 headers.
Fixing this triggered an assert when importing a constant initialized
`wchar_t` variable, so that is also fixed. The reason is that `wchar_t`
is mapped to `Unicode.Scalar`, which cannot be directly initialized by
integer literals in Swift, triggering an assert when looking up the
protocol conformance for `_ExpressibleByBuiltinIntegerLiteral`.
rdar://162074714
Since the compiler invokation performing the macro expansion dump
redirects its stderr output, any errors are not displayed by default.
This is extra problematic for test failures in CI. By performing the
compiler invokation with -verify first, errors are shown.
Importing clang submodules results in an implicit import of the
top-level module as well. This can result in the same TLM being imported
many different times, if multiple submodules are imported from the same
module. This deduplicates these imports.
Other imports are not expected to be duplicated, so care is taken to
only deduplicate clang TLM imports.
Non-explicit submodules don't need to be explicitly added to the list of
imports to be visible, since their decls are implicitly exported. Skip
these modules even when present in the list of imports. Explicit
submodules are imported *regardless* of whether another module
imports them however.
The imported top-level module inherits the imports of all its
(transitive) submodules. Since multiple submodules can import the same
modules these need to be deduplicated to avoid redundant work.
This flag dumps all imports for each SourceFile after it's gone through
import resolution. It is only intended for testing purposes.
There are other ways to print imports, but they don't correspond 1:1 to
the imports actually resolved, which is a bit problematic when testing
implicit clang module imports.
Decls in Swift wrapper module may not originate in the top-level clang
module with the same name, since decls in clang submodules are dumped
into the top-level module. This is because Swift has no concept of
submodules. To make sure that any imported decl has access to the same
symbols as the original clang decl had, all transitive submodules, and
their imports, are added as implicit imports of the wrapper module. This
is necessary in the case where a submodule is marked `explicit`.
The content in explicit submodules isn't normally made visible when
importing the parent module. Decls from explicit submodules still
end up in the top-level wrapper module however, so in Swift they do
still need to be visible from the top-level module. This is relevant
for macro expansions, so that they can refer to the same types as the
original decl.
When macros like _SwiftifyImport are added to a wrapper module for a
clang module, they may need to refer to symbols declared in another
clang module that the wrapped module imports (e.g. because they are used
in the original signature). This adds all the imported clang modules as
implicit imports to the wrapper module.
rdar://151611573
This enables the use of reference-counted foreign reference types on Windows. As it turns out, the assertion that was failing on Windows previously was unnecessary. This also enabled many of the tests on Windows.
rdar://154694125 / resolves https://github.com/swiftlang/swift/issues/82643
Swift validates the retain/release operations for foreign reference types to check for obvious errors, e.g. a wrong parameter type or return type.
That logic was only running for C++ foreign reference types. This patch enables it for C foreign reference types as well.
rdar://158609723
Previously, we skipped checking the return type of a function for safety
as we expected to warn at the use of the returned value:
let x = returnsUnsafe()
usesUnsafe(x) // warn here
Unfortunately, this resulted in missing some unsafe constructs that can
introduce memory safety issues when the use of the return value had a
different shape resulting in false negatives for cases like:
return returnsUnsafe()
or
usesUnsafe(returnsUnsafe())
This PR changes the analysis to always take return types of function
calls into account.
rdar://157237301
When we cannot respect the "destroy:" annotation, mark the type as
deprecated with a message thst says why there is a problem. There are
various potential problems:
* Multiple conflicting destroy functions
* Destroy functions that don't meet the pattern
* Type isn't imported as a move-only type
* Type has a non-trivial destructor (in C++)
