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.
We see some crashes presumably caused by invalid 'offset' returned from
macro plugins. Although we haven't been able to find a reproducer, guard
not to generate invalid source location by checking 'offfset' is within
the buffer length.
rdar://125625879
Rather than adding custom parsing to SwiftSyntax, we can parse this as a custom attribute and convert it to a built-in one in ASTGen. Test that this works correctly (and fix a bug where it wasn’t).
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.
[transferring] Implement transferring result and clean up transferring param support by making transferring a bit on param instead of a ParamSpecifier.
Instead it is a bit on ParamDecl and SILParameterInfo. I preserve the consuming
behavior by making it so that the type checker changes the ParamSpecifier to
ImplicitlyCopyableConsuming if we have a default param specifier and
transferring is set. NOTE: The user can never write ImplicitlyCopyableConsuming.
NOTE: I had to expand the amount of flags that can be stored in ParamDecl so I
stole bits from TypeRepr and added some logic for packing option bits into
TyRepr and DefaultValue.
rdar://121324715
And remove the `-disable-experimental-parser-round-trip` flag from borrowing
switch tests now that the SwiftSyntax parser supports them with
https://github.com/apple/swift-syntax/pull/2487.
When built as part of the compiler toolchain SwiftSyntax is built with library
evolution enabled. This means that switches over enums from SwiftSyntax must
include a default case to be considered exhaustive, or a warning will be
emitted. This change suppresses those warnings by adding `@unknown default`
cases wherever they are expected. As a compromise, these `@unknown default`
cases are wrapped with a `#if` to ensure they are only included in the CMake
build of ASTGen, but continue to be omitted from the SPM build which compiler
engineers use to iterate on ASTGen's implementation. This is needed to avoid
generating the opposite warning during the SPM build, since the compiler thinks
the `@unknown default` case is superfluous when SwiftSyntax is built
non-resiliently. As an aside, this catch-22 is a bummer and I think we should
change the compiler to suppress the unreachable default warning when the
default is annotated `@unknown`.
