We've started seeing build failures where the conformance of a `std::vector` instantiation to `CxxVector` is missing. This was because the LifetimeDependenceInfoRequest triggers the protocol conformance table for the instantiation to be built before the synthesized conformance gets added.
This works around the issue by preventing LifetimeDependenceInfoRequest from running for the synthesized default argument generator function, which was the culprit of this particular failure.
rdar://155977071
This patch re-enables diagnostics for unannotated C++ functions or
methods returning `SWIFT_SHARED_REFERENCE` types. These warnings now
fire only **once per source location**, even in the presence of multiple
template instantiations. This avoids diagnostic duplication that was a
key source of noise in the compilation of larger codebases.
These warnings were previously disabled starting in **Swift 6.2** via
[PR-#81411](https://github.com/swiftlang/swift/pull/81411) due to
concerns around false positives and excessive duplication in projects
adopting C++ interop. This patch addresses the duplication issue by
adding source-location-based caching, which ensures that a warning is
emitted only once per source location, even across template
instantiations with different types.
However, the false positive issue remains to be investigated and will be
addressed in a follow-up patch. Until that happens, the warnings are
gated behind a new experimental feature flag:
`WarnUnannotatedReturnOfCxxFrt`. This feature will be enabled by default
only after thorough qualification and testing on large C++ codebases.
rdar://154261051
We hit an assert failure do to creating a range where the begin was a
valid source location while the end range was an invalid one.
Unfortunately, I was not able to create a minimal reproducer but I was
able to verify that this fix works because I was able to reproduce this
issue while compiling Swift with a patched version of Clang.
rdar://155379027
When importing custom availability domains with dynamic predicates from Clang
modules, synthesize predicate functions for `if #available` queries and call
them when generating SIL.
Resolves rdar://138441312.
`-Xcc` flags are internal to the C compiler; we have `-vfsoverlay` now
which directly passes the VFS overlay. Because the VFS overlay flags are
automatically passed along to the clang scanner, we need to pass along
`-vfsoverlay` to the Swift frontend to ensure that any VFS overlays are
honoured. Most likely this was a workaround for `-vfsoverlay` not
getting propagated originally and when the restriction was lifted the
exercised codepath was not heavily tested.
When MemberImportVisibility is enabled we failed to find certain base
methods from the extensions when said base methods are imported from
C++.
rdar://154887575
This improves support for initializing instances of `std::optional` from Swift. Previously only a null optional could be initialized directly from Swift. Now instantiations of `std::optional` will get a Swift initializer that takes the wrapped value as a parameter.
rdar://118026392
This makes it possible to use trigger import-as-member for C++ functions declared within namespaces. Previously only functions declared at the file level were supported.
rdar://138930205
LookupOverloadedBinOp stores `Args` for later use, so store the
backing array on the stack instead of using a temporary.
This fixes a crash that appeared under some build configurations.
Related to rdar://154291418
Most of the logic for C++ foreign reference types can be applied to C types as well. Swift had a compiler flag `-Xfrontend -experimental-c-foreign-reference-types` for awhile now which enables foreign reference types without having to enable C++ interop. This change makes it the default behavior.
Since we don't expect anyone to pass `experimental-c-foreign-reference-types` currently, this also removes the frontend flag.
rdar://150308819
This is a follow-up to https://github.com/swiftlang/swift/pull/82085
which made it so async variant doesn't get `@Sendable` inferred because
the proposal specified that inference should happen only on completion
handler parameter type of a synchronous variant of an imported API.
This runs into implementation issues related to thunking in some
cases were async convention expects the type of a completion handler
to match exactly for both variants of the imported API.
Resolves: rdar://154695053
When improving the speed of dependency scanning when the new clang API
to speed up bridging, some unintended change was introduced. This
restore the scanner to the behavior before #81454
rdar://153851818
We synthesize a Swift function that only calls a C++ funtion that
produces the default argument. We produce this function for each module
that imports the C++ function with the default argument. This symbol
needs to be public as it is created in the context of the Clang module
and used from the Swift module. To avoid the linker errors, we always
emit this function into the client which is also the right thing to do
as the whole body is a single function call.
rdar://138513915
of the macro in the currently laoded macro module
Stdlib macros are shipped with the SDK, so we need to make sure that the
way we invoke the macro matches the version of the macro in the SDK.
This patch skips the `spanAvailability` parameter if it isn't present.
There's no good way to test this, because we will always pick up the
current macro in our llvm-lit test suite, but I've tested it manually.
rdar://152278292
Integer literal expressions with types that are not of type `int` are
printed with a suffix to indicate the type (e.g. `123U` or `456L` for
`unsigned` and `long`). This is not valid syntax for integer literals in
Swift, so until we fully translate the count expr syntax to Swift we
need to avoid importing these count expressions.
Also fixes some -Werror related stuff in test cases.
rdar://154141719
This adds support for `swift_name` attribute being used with C++ types that are declared within namespaces, e.g.
```
__attribute__((swift_name("MyNamespace.MyType.my_method()")))
```
Previously import-as-member would only accept a top-level unqualified type name.
rdar://138934888
Previously, we would get two copies, one accessing the pointee and one
when we pass the pointee as a method as the implicit self argument.
These copies are unsafe as they might introduce slicing. When
addressable paramaters features are enabled, we no longer make these
copies for the standard STL types. Custom smart pointers can replicate
this by making the lifetime dependency between the implicit object
parameter and the returned reference of operator* explicit via a
lifetime annotation.
rdar://154213694&128293252&112690482
