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
GCC warning:
```
/llvm-project/clang/lib/APINotes/APINotesYAMLCompiler.cpp:574:6: warning: ‘void {anonymous}::Module::dump()’ defined but not used [-Wunused-function]
574 | void Module::dump() {
| ^~~~~~
```
This annotates the dump methods in APINotes to indicate that they are
unused as they are meant for debugging purposes. This avoids an
unnecessary warning.
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
_Nullable_result generally like _Nullable, except when being imported into a
swift async method. rdar://70106409
Differential revision: https://reviews.llvm.org/D92495
