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.
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>
Literal migration would result in dyn_cast_if_present (see the
definition of PointerUnion::dyn_cast), but this patch uses dyn_cast
because we expect AnyFunc to be nonnull.
Adding support to APINotes to annotate C++ methods and functions with
`swift_attr("returns_retained")` and `swift_attr("returns_unretained")`
rdar://141007510
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.
It is common practice in C to declare anonymous tags that are
immediately given a typedef name, e.g.,
typedef enum { ... } MyType;
At present, one can only express API notes on the typedef. However, that
excludes the possibility of tag-specific notes like EnumExtensibility.
For these anonymous declarations, process API notes using the typedef
name as the tag name, so that one can add API notes to `MyType` via the
`Tags` section.
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 fixes a crash during `CXXMethod->getName()` in
`Sema::ProcessAPINotes`: we were trying to get the name of a C++ method
as a string, which fails with an assertion if the name is not a simple
identifier.
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
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.
This patch moves language- and target-specific functions out of
`SemaDeclAttr.cpp`. As a consequence, `SemaAVR`, `SemaM68k`,
`SemaMSP430`, `SemaOpenCL`, `SemaSwift` were created (but they are not
the only languages and targets affected).
Notable things are that `Sema.h` actually grew a bit, because of
templated helpers that rely on `Sema` that I had to make available from
outside of `SemaDeclAttr.cpp`. I also had to left CUDA-related in
`SemaDeclAttr.cpp`, because it looks like HIP is building up on top of
CUDA attributes.
This is a follow-up to #93179 and continuation of efforts to split
`Sema` up. Additional context can be found in #84184 and #92682.
Add `environment` parameter to Clang availability attribute. The allowed
values for this parameter are a subset of values allowed in the
`llvm::Triple` environment component. If the `environment` parameters is
present, the declared availability attribute applies only to targets
with the same platform and environment.
This new parameter will be initially used for annotating HLSL functions
for the `shadermodel` platform because in HLSL built-in function
availability can depend not just on the shader model version (mapped to
`llvm::Triple::OSType`) but also on the target shader stage (mapped to
`llvm::Triple::EnvironmentType`). See example in #89802 and
microsoft/hlsl-specs#204 for more details.
The environment parameter is currently supported only for HLSL.
Fixes#89802
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
