Using the same feature set logic as experimental features, provide
feature names for "future" features, which are changes that will
become available with Swift 6. Use the feature check when determining
whether to implementation the feature instead of a language version
check, and map existing flags for these features (when available) over
to the feature set.
As an internal implementation detail, this makes it easier to reason
about when specific features are enabled (or not). If we decide to go
with piecemeal adoption support for features, it can provide an
alternative path to enabling features that feeds this mechanism.
Experimental features can only be enabled in non-production (+Asserts)
builds. They can be detected with `hasFeature` in the same manner as
"future" features.
The `-enable-experimental-feature X` flag will also look for future
features by that name, so that when an experimental feature becomes an
accepted future feature, it will still be enabled in the same manner.
Switch variadic generics over to this approach, eliminating the
specific LangOption for it.
* InterfaceGen reports a primary associated type as a reference to the
'associatedtype' declaration
* CursorInfo on a primary associated type returns information of the
'associatedtype' declaration
rdar://93275458
If we have an internal function with a `_specialize` attribute that has
a `targetFunction:` parameter we want the function to appear in the
.swiftinterface file such that the exported specialization can be picked up by
the compiler.
- Add a `[reflection]` bit to `alloc_box` instructions, to indicate that a box
should be allocated with reflection metadata attached.
- Add a `@captures_generics` attribute to SILLayouts, to indicate a type layout
that captures the generic arguments it's substituted with, meaning it can
recreate the generic environment without additional ABI-level arguments, like
a generic partial application can.
There was a window where the PrimaryAssociatedTypes feature guarded the old
syntax; let's make sure we don't see breakage if a new standard library is
used with an old compiler.
This currently doesn't check for inherited docs, ie. either the
imported declaration has docs or it doesn't. There's also a few odd
cases with mixed doc types and when each line is prefixed with '*', but
it's good enough for an initial implementation.
Moves UTF8 sanitisation out of ASTPrinter.h and into Unicode.h so that
it can be used here as well.
Resolves rdar://91388603.
Since this implementation is exposed to users, we want to make it nice.
* Don't use 'unsafelyUnwrapped' which is usually not recommended to use
* Don't access 'container.allKeys' multiple times as it's a computed
property
rdar://89150202
We need to check the feature availability of _unavailableFromAsync
before it gets picked up in the swift interface file. This updates the
compiler to provide the necessary wrappings for that check.
and make `@_unsafeInheritExecutor` a suppressible feature.
Some language features are required in order to parse a
declaration correctly, but some can safely be ignored.
For the latter, we'd like the module interface to simply
contain the declaration twice, once with the feature and
once without. Some basic support for that was already
added for the SpecializeAttributeWithAvailability feature,
but it didn't interact correctly with required features
that might be checked in the same `#if` clause (it simply
introduced an `#else`), and it wasn't really set up to
allow multiple features to be handled this way. There
were also a few other places that weren't updated to
handle this, presumably because they never coincided
with a `@_specialize` attribute.
Introduce the concept of a suppressible feature, which
is anything that the ASTPrinter can modify the current
PrintOptions in order to suppress. Restructure the
printing of compatibility checks so that we can print
the body multiple times with different settings.
Print required feature checks in an outer `#if...#endif`,
then perform a separate `#if...#else...#endif` within
if we have suppressible features. If there are multiple
suppressible features, check for the most recent first,
on the assumption that it will imply the rest; then
perform subsequent checks with an `#elsif` clause.
This should be a far more solid foundation on which to
build compatibility checks in the future.
`@_unsafeInheritExecutor` needs to be suppressible
because it's been added to some rather important
existing APIs. Simply suppressing the entire decl will
effectively block old tools from using a new SDK to
build many existing projects (if they've adopted
`async`). Dropping the attribute changes the semantics
of these functions, but only if the compiler features
the SE-0338 scheduling change; this is a very narrow
window of main-branch development builds of the tools,
none of which were officially released.
SE-0338 changed the execution of non-actor async functions
so that they always hop to the generic executor, but some
functions need a way to suppress this so that they inherit
the caller's executor.
The right way to implement this is to have the caller pass
down the target executor in some reliable way and then
switch to it in all the appropriate places in the caller.
We might reasonably be able to build this on top of isolated
parameters, using some sort of default argument, or we might
need a wholly novel mechanism.
But those things are all ABI-breaking absent some sort of
guarantee about switching that we probably don't want to make,
and unfortunately we have functions in the library which we
need to export that need to inherit executors. So in the
short term, we need some unsafe way of getting back to the
previous behavior.
The RequirementSignature generalizes the old ArrayRef<Requirement>
which stores the minimal requirements that a conforming type's
witnesses must satisfy, to also record the protocol typealiases
defined in the protocol.
