Usage of Span was temporarily behind an experimental feature flag. Now
that SE-0447 has been accepted, remove the experimental feature flag and
allow Span usage everywhere.
Implements rdar://144819992.
Map the lifetime dependencies described in terms of the formal AST-level parameters
to the correct parameter(s) in the lowered SIL function type. There can be 0, 1,
or many SIL parameters per formal parameter because of tuple exploding. Also,
record which dependencies are on addressable parameters (meaning that the dependency
includes not only the value of the parameter, but its specific memory location).
Introduce a marker protocol SendableMetatype that is used to indicate
when the metatype of a type will conform to Sendable. Specifically,
`T: SendableMetatype` implies `T.Type: Sendable`. When strict
metatype sendability is enabled, metatypes are only sendable when `T:
SendableMetatype`.
All nominal types implicitly conform to `SendableMetatype`, as do the
various builtin types, function types, etc. The `Sendable` marker
protocol now inherits from `SendableMetatype`, so that `T: Sendable`
implies `T.Type: Sendable`.
Thank you Slava for the excellent idea!
Keep track of all of the type parameters and archetypes that are captured
by a local function or closure. Use that information to diagnose cases
where a non-Sendable metatype crosses an isolation boundary.
This would make sure that async function types marked as `@execution(caller)`
have correct isolation.
Also defines all of the possible conversions to and from `caller`
isolated function types.
Although it's not used anymore we still have to support it to be able to read old Swift.interface files which still contain the builtin.
rdar://144781646
* Instead of hoisting VarDecl in the bridging functions, do it in
ASTGen.
* Introduce `Decl::forEachDeclToHoist` to handle VarDecls in
PatternBindingDecl, and EnumElementDecl in EnumCaseDecl.
* Intorduce `withBridgedSwiftClosure(closure:call:)` as a callback
mechanism between Swift and C++
* In `generate(sourceFile:)`, instead of using `generate(codeBlockItem:)`
handle `CodeBlockItemSyntax.Item` manually to handle `TLCD` wrapping
and `VarDecl` hoisting.
* Make `generate(variableDecl:)` handle TLCD correctly.
There are a few places in the AST where we use `uint64_t` as
`ArrayRef`'s size type. Even though of these `uint64_t` size fields are
actually defined as bitfields with a maximum value of 32, but
unfortunately it's not taken into account and clang complains about
the implicit cast.
The same attempt was made in 073905b573,
but several new places were added since then.
https://github.com/swiftlang/swift/pull/72659 turned out to have some
source compatibility fallout that we need to fix. Instead of introducing
yet another brittle compatibility hack, stop emitting errors about a
missing `any` altogether until a future language mode.
Besides resolving the compatibility issue, this will encourage
developers to adopt any sooner and grant us ample time to gracefully
address any remaining bugs before the source compatibility burden
resurfaces.
A subsequent commit adds a diagnostic group that will allow users to
escalate these warnings to errors with `-Werror ExistentialAny`.
Instead of canonicalizing platform versions during parsing and storing two
versions, just canonicalize the parsed version on-demand when its requested.
Initializers should always have Swift names that have the special `DeclBaseName::createConstructor()` base name. Although there is an assertion to this effect in the constructor for ConstructorDecl, ClangImporter did not actually reject custom Swift names for initializers that violated this rule. This meant that asserts compilers would crash if they encountered code with an invalid `swift_name` attribute, while release compilers would silently accept them (while excluding these decls from certain checks since lookups that were supposed to find all initializers didn’t find them).
Modify ClangImporter to diagnose this condition and ignore the custom Swift name.
