ClangImporter already had some logic in place to rename certain unsafe
C++ methods to make sure their name indicates unsafety. With the recent
push for auditability, we have a new @unsafe attribute so we can
automate parts of the auditing process. This patch makes sure whenever
we rename a method as "Unsafe", we also add the @unsafe attribute.
The semantics of returning independent value already matches what
immortal lifetimes are within Swift. This patch makes sure this
annotation works as expected with non-escapable types.
rdar://137671642
Occasionally, when the Swift compiler emits a diagnostic for a construct
that was imported from C++ we get a diagnostic with unknown location.
This is a bad user experience. It is particularly bad with the
borrow-checker related diagnostics. This patch extends the source
location importing to declarations in ClangImporter. There are some
invariants enforced by the Swift compile, e.g., a source range is
comprised of two valid source locations or two invalid ones. As a
result, this patch adds approximate source locations to some separators
like braces or parens that are not maintained by Clang. Having slightly
incorrect ranges in this case is better than emitting unknown source
locations.
Based on feedback in PR https://github.com/swiftlang/swift/pull/69460, enabling indexing for synthesized decls because they are usable by users and make sense to appear in the indexstore.
Sets `synthesized` on some additional decls:
- derived `hashInto(...)`
- Objc properties and methods derived from Objc protocols
https://github.com/apple/swift/issues/67446
Swift should never try to import C++ structs that are not fully defined. This is because Clang can't synthesize implicit members of such types, which might be necessary for Swift, e.g. a copy constructor.
This adds an assertion that makes sure that C++ structs are considered to be fully defined by Clang. This condition should already be satisfied.
This type is non-copyable and non-moveable despite having a defaulted move constructor. It cannot currently be expressed in Swift. Let's not try to import it into Swift.
rdar://138123064 / resolves https://github.com/swiftlang/swift/issues/76809
When a type is explicitly annotated as escapable or non-escapable it has
requirements about the lifetime annotations. This patch introduces
diagnostics to detect that.
* [cxx-interop] Add Hashable conformance to imported enums
Previously, imported enums only conformed to RawRepresentable and Equatable,
so they could not be used as members of a Set or keys of a Dictionary.
This patch adds Hashable conformance to give them that ability,
as well as some test cases to clarify the expected behavior.
Existing test cases are updated to reflect this new conformance.
rdar://129713687
For now, this logic is used for importing fewer unannotated types as
unsafe. In the future, this logic will be used by escapability inference
for other (non-aggregate) types.
In this mode all C++ types are imported as unsafe by default. Users
explicitly marking types are escapable or not escapable can make them
imported as safe. In the future, we also want to import unannotated
functions as unsafe and add more logic to infer types that are actually
safe, like agregates of escapable types.
ModuleDecl kept track of all of the source files in the module so that it
could find the source file containing a given location, which relied on
a sorted array all of these source files. SourceManager has its own
similar data structure for a similar query mapping the locations to
buffer IDs.
Replace ModuleDecl's dats structure with a use of the SourceManager's version
with the mapping from buffer IDs to source files.
The lifetimebound annotations are now imported as lifetime dependencies.
This works for basic cases but there are still some parts missing:
* Support lifeitmebound annotations on constructors
* A way to represent immortal/static lifetimes on the C++ side
