The attribute declares that a struct contains "sensitive" data.
It enforces that the contents of such a struct value is zeroed out at the end of its lifetime.
In other words: the content of such a value is not observable in memory after the value's lifetime.
Also add an experimental feature `Sensitive` with which the attribute can be enabled.
The model for associated types hasn't been fully worked-out for
noncopyable generics, but there is some support already that is being
used by the stdlib for an internal-only (and rather cursed) protocol
`_Pointer` to support `UnsafePointer`, etc.
This patch gates the existing experimental support for associated types
behind a feature flag. This flag doesn't emit feature-guards in
interfaces, since support for it is tied closely to NoncopyableGenerics
and has been there from its early days.
To preserve compatibility with older compilers that do not allow `IsolatedAny`
to be enabled in production compilers, use an alias experimental feature when
building the stdlib (`IsolatedAny2`).
Also, add `@_allowFeatureSuppression(IsolatedAny)` in a couple spots it was
forgotten.
Partially resolves rdar://125138945
When printing declarations with `NoncopyableGenerics2` suppressed we must avoid
printing the `@_preInverseGenerics` attribute and any `borrowing` or
`consuming` parameter ownership modifiers.
The `.swiftinterface` of the standard library must remain compatible with some
older compilers. Unfortunately, some of those older compilers do not allow the
experimental feature `NoncopyableGenerics` to be enabled in production. To
allow the stdlib to build with non-copyable generics enabled and still have the
older compilers consume its interface, we have to use a new experimental
feature identifier that they do not know about.
Partially resolves rdar://125138945
• ObjCImplementation controls @implementation on extensions
• CImplementation controls @implementation and @_objcImplementation on cdecl functions
Why the difference between them? Because `@_objcImplementation extension` has already been adopted pretty widely, while `@_objcImplementation @_cdecl` is very new.
allow a more standard way to pass experimental features
from build systems. Also moved other flags relevant to
diagnostics from Frontend options to Lang options.
Ref: rdar://124648653
Allow `@_implements` to be expressed in an extension of the protocol in
which the associated type is defined. Use this to uncomment an
intended use of `@_implements` in `Sequence` that could be used to
replace a longstanding hack for associated type inference.
Since this change means that the standard library module interface
won't be accepted by older compilers, introduce a suppressible feature
ssociatedTypeImplements` that covers the use of `@_implements` on type
declarations. This will hide the `@_implements` attribute from older
compilers.
If an extension isn't imported either directly or via a transitive
(`@_exported`) import, its members should not be visible to name
lookup. Implement this behavior behind the experimental flag
ExtensionImportVisibility.
This allows us to remove their explicit `UNINTERESTING_FEATURE` entries for
them FeatureSet.cpp. All of these features have been present in the compiler
since at least Swift 5.8.
NFC.
Our standard conception of suppressible features assumes we should
always suppress the feature if the compiler doesn't support it.
This presumes that there's no harm in suppressing the feature, and
that's a fine assumption for features that are just adding information
or suppressing new diagnostics. Features that are semantically
relevant, maybe even ABI-breaking, are not a good fit for this,
and so instead of reprinting the decl with the feature suppressed,
we just have to hide the decl entirely. The missing middle here
is that it's sometimes useful to be able to adopt a type change
to an existing declaration, and we'd like older compilers to be
able to use the older version of the declaration. Making a type
change this way is, of course, only really acceptable for
@_alwaysEmitIntoClient declarations; but those represent quite a
few declarations that we'd like to be able to refine the types of.
Rather than trying to come up with heuristics based on
@_alwaysEmitIntoClient or other sources of information, this design
just requires the declaration to opt in with a new attribute,
@_allowFeatureSuppress. When a declaration opts in to suppression
for a conditionally-suppressible feature, the printer uses the
suppression serially-print-with-downgraded-options approach;
otherwise it uses the print-only-if-feature-is-available approach.
To maintain source compatibility, SE-0352 does not open existentials
with "self-conforming" type, such as `any Error` or existentials based
on `@objc` protocols. The proposal specified that this behavior would
change in Swift 6. Implement that behavior change, which can be
enabled prior to Swift 6 with the upcoming feature
`ImplicitOpenExistentials` (as documented in SE-0362).
Fixes#70873 / rdar://120902975.
