The handling of multi-basic-block control flow in `defer` blocks looks like it
was left incomplete and completely untested; I fixed a few obvious problems but
it still completely lacks any analysis of conditional reinitializations. For now,
change it to treat attempted reinitializations as uses-after-consumes so we raise
reliable errors now instead of emitting code that causes memory corruption at
runtime. Fixes rdar://129303198.
TLDR: This makes it so that we always can parse sending/transferring but changes
the semantic language effects to be keyed on RegionBasedIsolation instead.
----
The key thing that makes this all work is that I changed all of the "special"
semantic changes originally triggered on *ArgsAndResults to now be triggered
based on RegionBasedIsolation being enabled. This makes a lot of sense since we
want these semantic changes specifically to be combined with the checkers that
RegionBasedIsolation turns on. As a result, even though this causes these two
features to always be enabled, we just parse it but we do not use it for
anything semantically.
rdar://128961672
Some compilers have the NoncopyableGenerics feature enabled via
interesting mechanisms but do not have ConformanceSuppression. To
support such compilers, the NoncopyableGenerics feature must appear
before ConformanceSuppression in the list of features. Otherwise, when
parsing the portion of the swiftinterface corresponding to an entity
which involves both features, the first check will be for
NoncopyableGenerics (which that old compiler has) and the code inside
will involve ConformanceSuppression (which that old compiler does not
have).
rdar://128611158
A few things:
1. Internally except for in the parser and the clang importer, we only represent
'sending'. This means that it will be easy to remove 'transferring' once enough
time has passed.
2. I included a warning that suggested to the user to change 'transferring' ->
'sending'.
3. I duplicated the parsing diagnostics for 'sending' so both will still get
different sets of diagnostics for parsing issues... but anywhere below parsing,
I have just changed 'transferring' to 'sending' since transferring isn't
represented at those lower levels.
4. Since SendingArgsAndResults is always enabled when TransferringArgsAndResults
is enabled (NOTE not vis-a-versa), we know that we can always parse sending. So
we import "transferring" as "sending". This means that even if one marks a
function with "transferring", the compiler will guard it behind a
SendingArgsAndResults -D flag and in the imported header print out sending.
rdar://128216574
The standard library defines
```
protocol BitwiseCopyable {}
typealias _BitwiseCopyable = BitwiseCopyable
```
For current compilers, `BitwiseCopyable` is a "known protocol".
For older compilers, it is not; instead `_BitwiseCopyable` is. So
print the following into the swiftinterface for those older compilers:
```
protocol _BitwiseCopyable {}
typealias BitwiseCopyable = _BitwiseCopyable
```
rdar://127755503
upcoming feature.
The bespoke flag still works as a way to enable the `NonfrozenEnumExhaustivity`
upcoming feature. `NonfrozenEnumExhaustivity` is enabled by default in the
Swift 6 language mode as errors, and enabled by default in the Swift 5 language
mode as warnings.
A vestigial remnant of it was left behind after
06921cfe84 in order to avoid a reverse
condfail when building old swiftinterfaces that define
```swift
func _copy<T>(_ value: T) -> T {
#if $BuiltinCopy
Builtin.copy(value)
#else
value
#endif
}
```
If the language feature is removed, though, such interfaces should again
be buildable because the branch where the language feature isn't defined
should be expanded.
rdar://127516085
Resilence support will require changes to the Objective-C runtime to expand support for metadata initialization functions. Add a separate experimental feature flag to help with staging that support in, and modify diagnostics to not suggest increasing the minimum deployment target for now.
Add the machinery to support suppression of inference of conformance to
protocols that would otherwise be derived automatically.
This commit does not enable any conformances to be suppressed.
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.
This didn't expose any missing imports in the sources of any of the standard
library modules, but that's not entirely surprising. Still, we should have the
feature enabled to test it and prevent regressions from creeping in before the
behavior becomes the default.
Exclude `ExtensionImportVisibility` from module interfaces.
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
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.
