SwiftConformsTo specifies an additional conformance that should be
applied on import. Allow this on typedefs, because those can be imported
as wrapper types.
This patch adds support in APINotes for annotating C++ user-defined
types with: `swift_attr("returned_as_unretained_by_default")`
This attribute allows to specify a default ownership convention for
return values of `SWIFT_SHARED_REFERENCE` c++ types. Specifically, it
marks all unannotated return values of this type as `unretained` (`+0`)
by default, unless explicitly overridden at the API level using
`swift_attr("returns_retained")` or `swift_attr("returns_unretained")`.
The corresponding Swift compiler support for this annotation enables
developers to suppress warnings about unannotated return ownership in
large codebases while maintaining safe and predictable ownership
semantics. By enabling this in APINotes, library authors can define this
behavior externally without needing to modify C++ source headers
directly.
### Example usage in APINotes:
```
- Name: RefCountedTypeWithDefaultConvention
SwiftImportAs: reference
SwiftDefaultOwnership: unretained
```
rdar://150764491
Adding support to APINotes to annotate C++ methods and functions with
`swift_attr("returns_retained")` and `swift_attr("returns_unretained")`
rdar://141007510
This allows annotating fields of C/C++ structs using API Notes.
Previously API Notes supported Objective-C properties, but not fields.
rdar://131548377
This allows adding a Clang attribute
`swift_attr("conforms_to:ModuleName.ProtocolName")` to C++ structs via
API Notes.
The Swift compiler respects this attribute when importing C++ types into
Swift by automatically declaring the C++ type as a conforming type to
the given Swift protocol.
rdar://131388824
This adds support for adding Clang attributes to C++ methods declared
within C++ records by using API Notes.
For instance:
```
Tags:
- Name: IntWrapper
Methods:
- Name: getIncremented
Availability: none
```
This is the first instance of something within a C++ record being
annotated with API Notes, so it adds the necessary infra to make a C++
record an "API Notes context".
Notably this does not add support for nested C++ tags. That will be
added in a follow-up patch.
rdar://131387880
We were storing extraneous data for certain Objective-C/C++ entities.
Specifically, for declarations that can be nested in another context
(such as functions) we were storing the kind of the parent context in
addition to its ID. The ID is always sufficient.
This removes the logically incorrect usages of `ContextTableKey` that
don't actually describe a context, but rather describe a single
declaration. This introduces `SingleDeclTableKey` to store that kind of
entities in a more compact and reasonable way.
API Notes now support in C++. In preparation for supporting C++ methods
in API Notes, this change renames the remaining usages of
`ObjCContextABC` into `ContextABC` to make it clear that those contexts
might actually be C++, not Objective-C.
This is NFC-ish.
Certain C++ types, such as `std::chrono::tzdb` in libstdc++, are
non-copyable, but don't explicitly delete their copy constructor.
Instead, they trigger template instantiation errors when trying to call
their implicit copy constructor. The Swift compiler inserts implicit
copies of value types in some cases, which trigger compiler errors for
such types.
This adds a Clang API Notes attribute that allows annotating C++ types
as non-copyable in Swift. This lets the Swift compiler know that it
should not try to instantiate the implicit copy constructor for a C++
struct.
rdar://127049438
This upstreams a part of the C++ namespaces support in Clang API Notes.
The complete patch was recently merged downstream in the Apple fork: https://github.com/apple/llvm-project/pull/7230.
This patch only adds the parts of the namespace support that can be cleanly applied on top of the API Notes infrastructure that was upstreamed previously.
Differential Revision: https://reviews.llvm.org/D159092
This adds the skeleton for serializing out the APINotes data from the
APINotes. The writer uses a private implementation pattern to reduce
the exposed surface to just the programmatic representation of the
APINotes and not expose the details of the bitcode encoding. The format
itself is not considered stable and should only be accessed through the
APINotes Reader and Writer types.
Differential Revision: https://reviews.llvm.org/D92797
Reviewed By: martong
There are some trailing semicolons on namespaces in
clang/lib/APINotes/APINotesFormat.h. These result in warnings while
building and don't need to be there.
Reviewed By: compnerd
Differential Revision: https://reviews.llvm.org/D105049
This adds the bitcode format schema required for serialization of the
YAML data to a binary format. APINotes are pre-compiled and re-used in
the binary format from the frontend. These definitions provide the data
layout representation enabling writing (and eventually) reading of the
data in bitcode format.
This is extracted from the code contributed by Apple at
https://github.com/llvm/llvm-project-staging/tree/staging/swift/apinotes.
Differential Revision: https://reviews.llvm.org/D91997
Reviewed By: Gabor Marton
