The new `DECL_ATTR_FEATURE_REQUIREMENT` macro in DeclAttr.def can be used to declare that an attribute should only be available when a related language feature is enabled.
Effects:
• `#if hasAttribute(someAttr)` will return `false` unless the required feature is enabled.
• Code completion will not include the attribute unless the required feature is enabled.
• `TypeChecker::checkDeclAttributes()` diagnoses non-implicit uses of the attribute.
Add this mechanism and use it to tie @abi to the ABIAttribute feature. Also design tests for it.
This attribute will allow you to specify an alternate version of the declaration used for mangling. It will allow minor adjustments to be made to declarations so long as they’re still compatible at the calling convention level, such as refining isolation or sendability, renaming without breaking ABI, etc.
The attribute is behind the experimental feature flag `ABIAttribute`.
The `@differentiable` and `@derivative` attributes need a parent pointer. Move the code to populate it from Parser to AST so it can be more easily shared between the parsers.
Done in preparation for similar code to be added for `@abi`.
This convenience returns an optional `SemanticAvailableAttr` (since in the
future, lookup of the `AvailabilityDomain` can fail). It replaces
`Decl::getDomainForAvailableAttr()`, since most callers will need to form a
`SemanticAvailableAttr` with the resulting domain anyways.
This new attribute iterator returned from the query makes it simpler to
implement algorithms that need access to both the `AvailableAttr *` and its
corresponding `AvailabilityDomain`. This is also work towards making it
possible to return an optional `AvailabilityDomain` from
`Decl::getDomainForAvailableAttr()`.
Introduce an attribute to allow unsafe code within the annotated
declaration without presenting an unsafe interface to users. This is,
by its nature, and unsafe construct, and is used to document where
unsafe behavior is encapsulated in safe constructs.
There is an optional message that can be used as part of an audit
trail.
Since the introduction of custom attributes (as part of property
wrappers), we've modeled the context of expressions within these
attributes as PatternBindingInitializers. These
PatternBindingInitializers would get wired in to the variable
declarations they apply to, establishing the appropriate declaration
context hierarchy. This worked because property wrappers only every
applied to---you guessed it!---properties, so the
PatternBindingInitializer would always get filled in.
When custom attributes were extended to apply to anything for the
purposes of macros, the use of PatternBindingInitializer became less
appropriate. Specifically, the binding declaration would never get
filled in (it's always NULL), so any place in the compiler that
accesses the binding might have to deal with it being NULL, which is a
new requirement. Few did, crashes ensued.
Rather than continue to play whack-a-mole with the abused
PatternBindingInitializer, introduce a new CustomAttributeInitializer
to model the context of custom attribute arguments. When the
attributes are assigned to a declaration that has a
PatternBindingInitializer, we reparent this new initializer to the
PatternBindingInitializer. This helps separate out the logic for
custom attributes vs. actual initializers.
Fixes https://github.com/swiftlang/swift/issues/76409 / rdar://136997841
It replaces `DeclAttr::getUnavailable()` and `AvailableAttr::isUnavailable()`
as the designated way to query for the attribute that makes a decl unavailable.
The renamed decl is now stored exclusively in the split request evaluator
storage, which is more efficient since most availability attributes do not
specify a renamed decl.
Code review identified some incorrect UNIMPLEMENTED_CLONEs in DeclAttribute (thank you
Hamish and Rintaro). Fix those, and make sure this can't happen again by checking the type
signatures of clone() in every DeclAttribute subclass.
@lifetime(target: source1, source2...) where target can be any
parameter or 'self'. We cannot have @lifetime attributes with duplicate targets.
Also, update the internal data structures. Previously LifetimeEntry stored
pairwise (target, source) dependencies. Now, LifetimeEntry will store an optional
target descriptor and an array of source descriptors.
In #69257, we modified `ObjCReason` to carry a pointer to the @implementation attribute for the `MemberOfObjCImplementationExtension` kind. This made it mark the @implementation attribute as invalid, suppressing diagnostics from the ObjCImplementationChecker.
However, invalidating the attribute *also* causes it to be skipped by serialization. That isn’t a problem if the diagnostics are errors, since we’ll never emit the serialized module, but #74135 softened these diagnostics to warnings for early adopters.
The upshot was that if Swift emitted one of these warnings when it compiled a library, clients of that library would see the objcImpl extension as a normal extension instead. This would cause various kinds of mischief: ambiguous name lookups because implementations weren’t being excluded, overrides failing because an implementation was `public` instead of `open`, asserts and crashes in SILGen and IRGen because stored properties were found in seemingly normal extensions, etc.
Fix this by setting a separate bit on ObjCImplementationAttr, rather than the invalid bit, and modifying the implementation checker to manually suppress many diagnostics when that bit is set.
Fixes rdar://134730183.
Some requirement machine work
Rename requirement to Value
Rename more things to Value
Fix integer checking for requirement
some docs and parser changes
Minor fixes
Upstreams the necessary changes to compile references to `@backDeployed`
declarations correctly when a `macabi` target triple or a `-target-variant` is
specified.
If a protocol provides a deprecated default implementation for a requirement
that is not deprecated, the compiler should emit a warning so the programmer
can provide an explicit implementation of the requirement. This is helpful
for staging in new protocol requirements that should be implemented in
conforming types.
…for extensions. This change also removes @implementation(CategoryName); you should attach the category name to the @objc attribute instead. And there are small changes to how much checking the compiler will do on an @objc @implementation after the decl checker has discovered a problem with it.
