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
In Swift 6.1, we introduced warnings for C++ APIs returning
SWIFT_SHARED_REFERENCE types that lack the SWIFT_RETURNS_(UN)RETAINED
annotations. These warnings serve as a reminder to annotate APIs, as the
absence of these annotations can lead to arbitrary assumptions about the
ownership of returned SWIFT_SHARED_REFERENCE values. This could result
in both use-after-free (memory safety) bugs and memory leaks.
We have received feedback from a few adopters indicating potential false
positive cases where these warnings are triggered. Consequently, we have
decided to disable these warnings in Swift 6.2 and re-qualify the
warnings on larger projects to ensure their effectiveness and eliminate
false positives. Our intention is to re-enable the warnings in later
beta releases of Swift 6.2 once we have stronger evidence of their
effectiveness on large codebases and proof that there are no false
positives.
rdar://150937617
rdar://150800115
C++ namespaces are imported as enums. The importer triggered different
code path for functions in C++ namespaces and functions in the global
scope. As a result, we occasionally did not import the return type of
certain C++ functions in namespace scope.
This is a follow-up to d3e43bbe which resolved the issue for value types, but not for foreign reference types.
This change teaches IRGen that a base type of a C++ type might occupy less memory than its `sizeof`, specifically, it might only use `dsize` amount of memory.
rdar://147527755
It turns out the query to check the reference semantics of a type had
the side effect of importing some functions/types. This could introduce
circular reference errors with our queries. This PR removes this side
effect from the query and updates the test files. Since we do the same
work later on in another query, the main change is just the wording of
the diagnostics (and we now can also infer immortal references based on
the base types). This PR also reorders some operations, specifically now
we mark base classes as imported before we attempt to import template
arguments.
After these changes it is possible to remove the last feature check for
strict memory safe mode. We want to mark types as @unsafe in both
language modes so we can diagnose redundant unsafe markers even when the
feature is off.
In C++, a primary base class that is placed in the beginning of the type's memory layout isn't always the type that is the first in the list of bases – the base types might be laid out in memory in a different order.
This makes sure that IRGen handles base types of C++ structs in the correct order.
This fixes an assertion in asserts-enabled compilers, and an out-of-memory error in asserts-disabled compilers. The issue was happening for both value types and foreign reference types. This change also includes a small refactoring to reuse the logic between the two code paths.
rdar://140848603
For types imported from C++, the original clang::TypeDecl is saved in
the swift::Type and reused for conversions back to clang::QualType.
However, the conversion did not account for foreign reference types,
which should be mapped to a pointer to the C++ record type, rather than
the record type itself.
This bug first appeared as a function template instantiation failure
due to a sanity check performed by SwiftDeclConverter::foreignReferenceTypePassedByRef()
but may also affect other round-tripping type conversions.
The added test case demonstrates the template instantiation scenario,
where templates were being used to overcome Swift/C++ interop's current
lack of support for class inheritance.
rdar://134979343
