Global actors have been an accepted language feature for a couple of compiler releases now, but the feature definition was associated with the `--enable-experimental-concurrency` flag. This caused some `.swiftinterface`s containing global actor declarations to be unparsable because the logic for surrounding declarations with the `$GlobalActors` feature guard was incomplete (for example, classes with a global actor attribute were not guarded even though the declarations of global actor types were).
Rather than trying to fix the logic of `usesFeatureGlobalActors()`, enable it by default.
Adds a test that demonstrates that modules defining and using public global actors produce module interfaces that can be parsed successfully.
Resolves rdar://100150703
* [SILOptimizer] Add prespecialization for arbitray reference types
* Fix benchmark Package.swift
* Move SimpleArray to utils
* Fix multiple indirect result case
* Remove leftover code from previous attempt
* Fix test after rebase
* Move code to compute type replacements to SpecializedFunction
* Fix ownership when OSSA is enabled
* Fixes after rebase
* Changes after rebasing
* Add feature flag for layout pre-specialization
* Fix pre_specialize-macos.swift
* Add compiler flag to benchmark build
* Fix benchmark SwiftPM flags
Remove the CMake configuration option `SWIFT_SWIFT_PARSER_ROUNDTRIP`.
Instead, whenever the "early" SwiftSyntax module is built, link the
Swift Swift parser into the compiler and related tools.
Introduce a new experimental feature `ParserRoundTrip` that can be
enabled to perform round-trip testing.
By using the keyword instead of the function, we actually get a much simpler
implementation since we avoid all of the machinery of SILGenApply. Given that we
are going down that path, I am removing the old builtin implementation since it
is dead code.
The reason why I am removing this now is that in a subsequent commit, I want to
move all of the ownership checking passes to run /before/ mandatory inlining. I
originally placed the passes after mandatory inlining since the function version
of the move keyword was transparent and needing to be inlined before we could
process it. Since we use the keyword now, that is no longer an issue.
This was already enabled as part of `-enable-implicit-dynamic` but this
new flag allows turning on opaque type erasure all by itself whether or
not `dynamic` is added explicitly.
rdar://97375478
Introduce the `-enable-upcoming-feature X` command-line argument to
allow one to opt into features that will be enabled in an upcoming language
mode. Stage in several features this way (`ConciseMagicFile`,
`ForwardTrailingClosures`, `BareSlashRegexLiterals`).
`@Sendable` on completion handlers imported from Objective-C has been
implemented for a while, but has been disabled in production builds
due to a number of problems we've encountered with rolling it out.
Introduce an experimental feature for `@Sendable` completion handlers
so we can iterate on this more before we enable it by default.
Part of rdar://85569247, which will cover re-landing this feature.
The new intrinsic, exposed via static functions on Task<T, Never> and
Task<T, Error> (rethrowing), begins an asynchronous context within a
synchronous caller's context. This is only available for use under the
task-to-thread concurrency model, and even then only under SPI.
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.
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.
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 key thing is that the move checker will not consider the explicit copy value
to be a copy_value that can be rewritten, ensuring that any uses of the result
of the explicit copy_value (consuming or other wise) are not checked.
Similar to the _move operator I recently introduced, this is a transparent
function so we can perform one level of specialization and thus at least be
generic over all concrete types.
This builtin never occurs in @inlinable code. But apparently we still
need to add a language feature for every builtin. This must allow
older compilers to reparse the library source (though I don't know why
that would ever happen!)
Fixes rdar://80525569 error: module 'Builtin' has no member named 'hopToActor')
Rather than using group task options constructed from the Swift parts
of the _Concurrency library and passed through `createAsyncTask`'s
options, introduce a separate builtin that always takes a group. Move
the responsibility for creating the options structure into IRGen, so
we don't need to expose the TaskGroupTaskOptionRecord type in Swift.
The `createTaskGroup` builtin has changed its signature and now requires
a type metadata argument. Change the feature accordingly so that
compilers with the new and old versions have disjoint feature sets.
Fixes rdar://79561865.
I added Builtin.buildMainActorExecutor before, but because I never
implemented it correctly in IRGen, it's not okay to use it on old
versions, so I had to introduce a new feature only for it.
The shim dispatch queue class in the Concurrency runtime is rather
awful, but I couldn't think of a reasonable alternative without
just entirely hard-coding the witness table in the runtime.
It's not ABI, at least.
1. Removes gating on -enable-experimental-concurrency.
2. Updates eff. prop tests to remove experimental flag,
and also adjusts some tests slightly to avoid things
that are still behind that flag.
