explicit existential types are enabled.
Note that existential metatypes still resolve to ExistentialMetatypeType,
but later this type can be replaced with ExistentialType(MetatypeType).
The new type, called ExistentialType, is not yet used in type resolution.
Later, existential types written with `any` will resolve to this type, and
bare protocol names will resolve to this type depending on context.
- Frontend: Implicitly import `_StringProcessing` when frontend flag `-enable-experimental-string-processing` is set.
- Type checker: Set a regex literal expression's type as `_StringProcessing.Regex<(Substring, DynamicCaptures)>`. `(Substring, DynamicCaptures)` is a temporary `Match` type that will help get us to an end-to-end working system. This will be replaced by actual type inference based a regex's pattern in a follow-up patch (soon).
- SILGen: Lower a regex literal expression to a call to `_StringProcessing.Regex.init(_regexString:)`.
- String processing runtime: Add `Regex`, `DynamicCaptures` (matching actual APIs in apple/swift-experimental-string-processing), and `Regex(_regexString:)`.
Upcoming:
- Build `_MatchingEngine` and `_StringProcessing` modules with sources from apple/swift-experimental-string-processing.
- Replace `DynamicCaptures` with inferred capture types.
-check-api-availability-only limits availability checking to the API
only, ensuring that was will appear in the swiftinterface is sound but
without raising issues about implementation details. This patch ensures
it correctly ignore non-public async functions as they wouldn't appear
in the API.
rdar://86174644
Extend the implicit Sendable request to produce an inherited
conformance when queried, rather than depending on the conformance
lookup table to always have the right entries. This acknowledges that
implicit Sendable needs to happen more at the type checking level than
the name-binding level, which is needed to eliminate cyclic
dependencies.
Adding the ability to add an optional message to the unavailable from
async attribute. This can be used to indicate other possible API to use,
or help explain why it's unavailable.
Use the explicit check for a Sendable conformance (even an unavailable
one) as the mechanism for determining whether to diagnose a
missing/unavailable Sendable conformance in a particular context.
With multi-statement closure inference enabled "outer candidates"
hack needs to be careful with its use of `isInvalid()` because some
of the declarations lookup finds might be coming from a multi-statement
closure that being type-checked, such declarations have to be avoided
as candidates, otherwise calling `isInvalid` on them results in a circular
type-checking.
Resolves: rdar://85843677
We were doing the conformance check through a lower-level interface that
didn't deal with the unavailable Sendable synthesis.
Fixes a spurious diagnostic reported via rdar://85894346.
With `-enable-experimental-string-processing`,
start lexing `'` delimiters as regex literals (this
is just a placeholder delimiter for now). The
contents of which gets passed to the libswift
library, which can return an error string to be
emitted, or null for success.
The libswift side isn't yet hooked up to the Swift
regex parser, so for now just emit a dummy
diagnostic for regexes starting with quantifiers.
If successful, build an AST node which will be
emitted as an implicit call to an
`init(_regexString:)` initializer of an in-scope
`Regex` decl (which will eventually be a known
stdlib decl).
Rather than only checking the sendability of captures at the point of
use, diagnose captures uniformly for the closure as a whole. Fixes a
case where we were missing a diagnostic due to an explicit capture,
rdar://85988937.
Non-isolated declarations in general do not require Sendable
diagnostics. However, we do need to make sure that `nonisolated let`
accesses to actor-isolated state are always cross-actor.
Fixes rdar://83371627.
