Implement the @export(implementation) and @export(interface) attributes
to replace @_alwaysEmitIntoClient and @_neverEmitIntoClient. Provide a
warning + Fix-It to start staging out the very-new
@_neverEmitIntoClient. We'll hold off on pushing folks toward
@_alwaysEmitIntoClient for a little longer.
If we have a custom attribute on a type that does a qualified lookup
into the same type, we need to be able to expand member attribute
macros for that type. As such, the check to see if we already have
a nominal for the attribute would hit a cycle. Limit this check such
that it only applies to local vars, which is the only case where it
actually matters.
rdar://163961797
Whenever we have a reference to a foreign function/variable in SIL, use
a mangled name at the SIL level with the C name in the asmname
attribute. The expands the use of asmname to three kinds of cases that
it hadn't been used in yet:
* Declarations imported from C headers/modules
* @_cdecl @implementation of C headers/modules
* @_cdecl functions in general
Some code within the SIL pipeline makes assumptions that the C names of
various runtime functions are reflected at the SIL level. For example,
the linking of Embedded Swift runtime functions is done by-name, and
some of those names refer to C functions (like `swift_retain`) and
others refer to Swift functions that use `@_silgen_name` (like
`swift_getDefaultExecutor`). Extend the serialized module format to
include a table that maps from the asmname of functions/variables over
to their mangled names, so we can look up functions by asmname if we
want. These tables could also be used for checking for declarations
that conflict on their asmname in the future. Right now, we leave it
up to LLVM or the linker to do the checking.
`@_silgen_name` is not affected by these changes, nor should it be:
that hidden feature is specifically meant to affect the name at the
SIL level.
The vast majority of test changes are SIL tests where we had expected
to see the C/C++/Objective-C names in the tests for references to
foreign entities, and now we see Swift mangled names (ending in To).
The SIL declarations themselves will have a corresponding asmname.
Notably, the IRGen tests have *not* changed, because we generally the
same IR as before. It's only the modeling at the SIL lever that has
changed.
Another part of rdar://137014448.
Expressed as `__swift_attr__("~Sendable")` this acts like `: ~Sendable`
on Swift type declarations and supersedes `@_nonSendable(_assumed)`.
Resolves: rdar://140928937
Removes the underscored prefixes from the @_section and @_used attributes, making them public as @section and @used respectively. The SymbolLinkageMarkers experimental feature has been removed as these attributes are now part of the standard language. Implemented expression syntactic checking rules per SE-0492.
Major parts:
- Renamed @_section to @section and @_used to @used
- Removed the SymbolLinkageMarkers experimental feature
- Added parsing support for the old underscored names with deprecation warnings
- Updated all tests and examples to use the new attribute names
- Added syntactic validation for @section to align with SE-0492 (reusing the legality checker by @artemcm)
- Changed @DebugDescription macro to explicitly use a tuple type instead of type inferring it, to comply with the expression syntax rules
- Added a testcase for the various allowed and disallowed syntactic forms, `test/ConstValues/SectionSyntactic.swift`.
When defining a C-compatible function with `@c`, we were emitting a
Swift function along with a C-compatible thunk. Stop doing that, and
instead only produce the C-compatible function. All uses of the
function will go through that C interface, just like if the function
were declared in C.
This also applies to `@c @implementation` functions, which are
declared in C but implemented in Swift. It does *not* apply to
`@_cdecl`, which will continue to produce both the Swift function and
C thunk to prevent an ABI break.
Fixes rdar://158888024.
Remove the DeclContext parameter from ResolveMacroRequest, we can now
retrieve the DeclContext either from the CustomAttr or macro expansion
expr/decl directly.
Introduce `DeclAttribute::attachToDecl` which is the now the main
entry point for associating an attribute with a decl. Different
attributes can implement `attachToDeclImpl` to add their custom logic.
Move DifferentiableAttr, DerivativeAttr, CustomAttr, and ABIAttr over
to this new logic.
Introduce CustomAttrOwner that can store either a Decl for an
attached attribute, or a DeclContext for e.g a type or closure
attribute. Store this on CustomAttr such that we can query it from
the name lookup requests.
The intent for `@inline(always)` is to act as an optimization control.
The user can rely on inlining to happen or the compiler will emit an error
message.
Because function values can be dynamic (closures, protocol/class lookup)
this guarantee can only be upheld for direct function references.
In cases where the optimizer can resolve dynamic function values the
attribute shall be respected.
rdar://148608854
Declarations that are unavailable at runtime because of an `@available`
attribute referencing a custom domain that was imported `@_spiOnly` should be
hidden from public swiftinterface files in `-library-level=api` modules. For
remaining declarations that do get printed in the public swiftinterface, skip
printing any `@available` attribute that refers to the domains from those
`@_spiOnly` dependencies. This allows API developers to control declaration
visibility using availability defined by another module.
Resolves rdar://156512028.
This can help work around problems when the names of a C++ declaration
and a Swift declaration would collide, or to temporarily work around
compiler bugs.
rdar://152838988&140802127&158843666
Since LayoutPrespecialization has been enabled by default in all compiler
invocations for quite some time, it doesn't make sense for it to be treated as
experimental feature. Make it a baseline feature and remove all the
checks for it from the compiler.
NFC *except* that I noticed a bug by inspection where we suppress
`@escaping` when print enum element types. Since this affects
recursive positions, we end up suppressing `@escaping` in places
we shouldn't. This is unlikely to affect much real code, but should
still obviously be fixed.
The new design is a little sketchy in that we're using `const` to
prevent direct use (and allow initialization of `const &` parameters)
but still relying on modification of the actual object. Essentially,
we are treating the `const`-ness of the reference as a promise to leave
the original value in the object after computation rather than a
guarantee of not modifying the object. This is okay --- a temporary
bound to a `const` reference is still a non-`const` object formally
and can be modified without invoking UB --- but makes me a little
uncomfortable.
Implements SE-0460 -- the non-underscored version of @specialized.
It allows to specify "internal" (not abi affecting) specializations.
rdar://150033316
By default (currently) the closure passed to a parameter with `@_inheritActorContext`
would only inherit isolation from `nonisolated`, global actor isolated or actor
context when "self" is captured by the closure. `always` changes this behavior to
always inherit actor isolation from context regardless of whether it's captured
or not.
It has indirect effects on the accessors, so it shouldn’t matter, but we can defensively redirect the query to the API counterpart anyway.
This was the last `InferredInABIAttr` attribute, so we can now remove all of the infrastructure involved in supporting attribute inference.
