Nested calls to importBaseMemberDecl() subvert its cache and compromise its idempotence, causing the semantic checker to spuriously report ambiguous member lookups when multiple ClangRecordMemberLookup requests are made (e.g., because of an unrelated missing member lookup).
One such scenario is documented as a test case: test/Interop/Cxx/class/inheritance/inherited-lookup-typechecker.swift fails without this patch because of the expected error from the missing member. Meanwhile, test/Interop/Cxx/class/inheritance/inherited-lookup-executable.swift works because it does not attempt to access a missing member.
This patch fixes the issue by only calling importBaseMemberDecl() in the most derived class (where the ClangRecordMemberLookup originated, i.e., not in recursive requests).
As a consequence of my patch, synthesized member accessors in the derived class directly invoke the member from the base class where the member is inherited from, rather than incurring an indirection at each level of inheritance. As such, the synthesized symbol names are different (and shorter). I've taken this opportunity to update the relevant tests to // CHECK for more of the mangled symbol, rather than only the synthesized symbol prefix, for more precise testing and slightly better readability.
rdar://141069984
The C++ span should be a non-escapable type but is imported as escapable
for backward compatibility reason. This is inherently unsafe, so make
sure std::span is imported as such. In the future, we plan to generate
safe overloads using Swift's Span and that will be the preferred way of
using the API.
When cloning the clang instance in ClangImporter to perform tasks like
PCM/PCH compilation, make two compiler instance to share the same
CASOptions so they can share the CAS ObjectStore and life time.
This fixes a case where clang emits a diagnostics in a source buffer that
gets mapped in via CAS, and mapped into swift source manager. While CAS has
the ownship from CompilerInvocation -> CASOptions -> CAS, if the
CompilerInvocation is deleted when the cloned instance is deleted, it
left an invalid buffer in the swift source manager.
rdar://141284501
This results in an automatic wrapper function with safe pointer types
when the imported function has bounds attributes. This exercises similar
pathways as the recently added functionality for specifying macros from
swift_attr. The new functionality is guarded by the experimental
language feature SafeInteropWrappers.
rdar://97942270
This teaches Swift to rebuild the CxxStdlib overlay module from its interface when using a C++ standard library that is not the platform default, specifically libc++ on Linux.
rdar://138838506
When explicitly asked not to load the C++ standard library, Swift should not emit warnings for missing libstdc++.
This fixes a compiler warning when building the Cxx module on Linux.
We only add conditional annotations because those do not break backward
compatibility (we might import span and similar view types as
non-escapable in the future). We inject these annotations in the
importer to make sure we have consistent behavior acress the different
standard library implementations. Once we can ship APINotes for the STL
and we have conditional escapability support in APINotes we can migrate
to that solution. But it is not possible as of today and Clang already
has precedent of injecting information for the STL with lifetimebound.
rdar://139065558
Since we can't do a proper "deep" clone of expression nodes, cloning
such a CustomAttr is necessarily shallow. In such cases, don't cache
the swift_attr source files at all, so we get fresh attribute nodes
for each such usage.
In rare scenarios, Swift was emitting diagnostics that looked like this:
```
warning: 'import_owned' swift attribute ignored on type 'basic_string': type is not copyable or destructible
```
This change makes sure the compiler does not emit these (incorrect) warnings. See the inline comment for more details.
DynamicRangePointerType and ValueTerminatedType are new Clang
types for -fbounds-safety, annotated with the 'ended_by' and the
'terminated_by' attributes. This adds visitors for these types in
ClangImporter so Swift still builds with Clang that has these new
types.
Swift compiler can try to import clang modules which might fail to load.
In this case, the clang diagnostic engine is reset to ignore the errors,
but the hard reset also clears out the states, including the diagnostics
options and current states. This will affect the future clang module
imports and diagnostics. Use a soft reset that only clears the errors
but not the other states.
rdar://139723218
Many existing C APIs for retaining references, including Apple's own, return
the reference. Support this pattern, along with the existing void return
signature, with when importing reference types from C++.
FunctionRefKind was originally designed to represent
the handling needed for argument labels on function
references, in which the unapplied and compound cases
are effectively the same. However it has since been
adopted in a bunch of other places where the
spelling of the function reference is entirely
orthogonal to the application level.
Split out the application level from the
"is compound" bit. Should be NFC. I've left some
FIXMEs for non-NFC changes that I'll address in a
follow-up.
Unfortunately, importing them as is results in ambiguous call sites.
E.g., std::vector::push_back has overloads for lvalue reference and
rvalue reference and we have no way to distinguish them at the call site
in Swift. To overcome this issue, functions with rvalue reference
parameters are imported with 'consuming:' argument labels.
Note that, in general, move only types and consuming is not properly
supported in Swift yet. We do not invoke the dtor for the moved-from
objects. This is a preexisting problem that can be observed with move
only types before this PR, so the fix will be done in a separate PR.
Fortunately, for most types, the moved-from objects do not require
additional cleanups.
rdar://125816354
The renamed decl is now stored exclusively in the split request evaluator
storage, which is more efficient since most availability attributes do not
specify a renamed decl.
Non-escapable types are now enabled by default. Use the new lifetime
dependence feature flag to gate interpreting lifetime annotations on the
C++ side and add tests to make sure we get the expected diagnostics when
the feaature flag is off.
Fixes an issue where parent type wasn't set for qualified ObjC
pointers which leads to crashes during Sema because non-pointer
uses are imported correctly.
Resolves: rdar://102564592
Rather than exposing an `addFile` member on
ModuleDecl, have the `create` members take a
lambda that populates the files for the module.
Once module construction has finished, the files
are immutable.
