SwiftConformsTo specifies an additional conformance that should be
applied on import. Allow this on typedefs, because those can be imported
as wrapper types.
Swift-versioned API notes get applied at PCM constrution time relying on
'-fapinotes-swift-version=X' argument to pick the appropriate version.
This change adds a new APINotes application mode with
'-fswift-version-independent-apinotes' which causes *all* versioned API
notes to get recorded into the PCM wrapped in 'SwiftVersionedAttr'
instances. The expectation in this mode is that the Swift client will
perform the required transformations as per the API notes on the client
side, when loading the PCM, instead of them getting applied on the
producer side. This will allow the same PCM to be usable by Swift
clients building with different language versions.
In addition to versioned-wrapping the various existing API notes
annotations which are carried in declaration attributes, this change
adds a new attribute for two annotations which were previously applied
directly to the declaration at the PCM producer side: 1) Type and 2)
Nullability annotations with 'SwiftTypeAttr' and 'SwiftNullabilityAttr',
respectively. The logic to apply these two annotations to a declaration
is refactored into API.
ArrayRef now has a new constructor that takes a parameter whose type
has data() and size(). This patch migrates:
ArrayRef<T>(X.data(), X.size()
to:
ArrayRef<T>(X)
These are identified by misc-include-cleaner. I've filtered out those
that break builds. Also, I'm staying away from llvm-config.h,
config.h, and Compiler.h, which likely cause platform- or
compiler-specific build failures.
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
Note that PointerUnion::dyn_cast has been soft deprecated in
PointerUnion.h:
// FIXME: Replace the uses of is(), get() and dyn_cast() with
// isa<T>, cast<T> and the llvm::dyn_cast<T>
This patch migrates uses of PointerUnion::dyn_cast to
dyn_cast_if_present (see the definition of PointerUnion::dyn_cast).
Note that we cannot use dyn_cast in any of the migrations in this
patch; placing
assert(!X.isNull());
just before any of dyn_cast_if_present in this patch triggers some
failure in check-clang.
Found assertion failures when using EXPENSIVE_CHECKS and running lit
tests for APINotes:
Assertion `left.first != right.first && "two entries for the same
version"' failed.
It seems like std::is_sorted is verifying that the comparison function
is reflective (comp(a,a)=false) when using expensive checks. So we would
get callbacks to the lambda used for comparison, even for vectors with a
single element in APINotesReader::VersionedInfo<T>::VersionedInfo, with
"left" and "right" being the same object. Therefore the assert checking
that we never found equal values would fail.
Fix makes sure that we skip the check for equal values when "left" and
"right" is the same object.
Note that PointerUnion::{is,get} have been soft deprecated in
PointerUnion.h:
// FIXME: Replace the uses of is(), get() and dyn_cast() with
// isa<T>, cast<T> and the llvm::dyn_cast<T>
I'm not touching PointerUnion::dyn_cast for now because it's a bit
complicated; we could blindly migrate it to dyn_cast_if_present, but
we should probably use dyn_cast when the operand is known to be
non-null.
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 https://github.com/apple/llvm-project/pull/8063.
If module FooCore is re-exported through module Foo (by using
`export_as` in the modulemap), look for attributes of FooCore symbols in
Foo.apinotes file.
Swift bundles `std.apinotes` file that adds Swift-specific attributes to
the C++ stdlib symbols. In recent versions of libc++, module std got
split into multiple top-level modules, each of them is re-exported
through std. This change allows us to keep using a single modulemap file
for all supported C++ stdlibs.
rdar://121680760
This fixes tests that are going to be upstreamed in the near future.
Currently they are failing downstream in the Apple open source fork.
Failing tests
Clang :: APINotes/retain-count-convention.m
Clang :: APINotes/types.m
Clang :: APINotes/versioned-multi.c
Clang :: APINotes/versioned.m
Since 2e5af56 got merged, Clang now enables `LangOpts.APINotesModules`
when reading a precompiled module that was built with API Notes enabled.
This is correct. The logic in APINotesManager needs to be adjusted to
handle this.
rdar://123526142
This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.
I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.
Note that llvm::support::endianness has been renamed to
llvm::endianness while becoming an enum class as opposed to an enum.
This patch replaces llvm::support::{big,little,native} with
llvm::endianness::{big,little,native}.
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 patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.
This is part of an effort to migrate from llvm::Optional to
std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
