A previous commit resulted in the swift interface for CxxStdlib
containing an `import CxxStdlib` for each submodule. This restores the
submodule names to `CxxStdlib.vector` etc.
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.
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 patch improves the warning for C++ APIs returning
`SWIFT_SHARED_REFERENCE` types but not annotated with either
`SWIFT_RETURNS_RETAINED` or `SWIFT_RETURNS_UNRETAINED` in the following
ways:
1. The warning for missing `SWIFT_RETURNS_(UN)RETAINED` annotations is
now emitted on Swift use sites, rather than while importing the API
(func/method decls).
- This logic is now implemented as a Misl Diagnostic in function
`diagnoseCxxFunctionCalls` in file lib/Sema/MiscDiagnostics.cpp.
- The warning is now triggered only when the API is actually used, which
reduces noise in large C++ headers.
- These warnings are still gated behind experimental-feature-flag `WarnUnannotatedReturnOfCxxFrt`
rdar://150800115
Cache the result of turning a `ValueDecl` into an `AvailabilityDomain`. Use
split caching to make the common case of the decl not representing an
availability domain efficient.
NFC.
Whenever we have a vector type, the escpability depends on the
escapability of the element type. This will enable us to consider more
types like std::vector<simd::float3> as safe by default.
rdar://157141552
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
This teaches ClangImporter to import C++ decls that are declared within `extern "C" { ... }`/`extern "C++" { ... }` blocks which are nested in namespaces.
rdar://139067788
