LLVM is presumably moving towards `std::string_view` -
`StringRef::startswith` is deprecated on tip. `SmallString::startswith`
was just renamed there (maybe with some small deprecation inbetween, but
if so, we've missed it).
The `SmallString::startswith` references were moved to
`.str().starts_with()`, rather than adding the `starts_with` on
`stable/20230725` as we only had a few of them. Open to switching that
over if anyone feels strongly though.
language feature, and suppress it for `Clock.measure`.
This allows the _Concurrency swiftinterface file to continue building with
compilers that do not support `OptionalIsolatedParameters`. The feature
suppression drops the `isolated` keyword and replaces `#isolation` with
`nil`.
Allow `@_implements` to be expressed in an extension of the protocol in
which the associated type is defined. Use this to uncomment an
intended use of `@_implements` in `Sequence` that could be used to
replace a longstanding hack for associated type inference.
Since this change means that the standard library module interface
won't be accepted by older compilers, introduce a suppressible feature
ssociatedTypeImplements` that covers the use of `@_implements` on type
declarations. This will hide the `@_implements` attribute from older
compilers.
We preserve the current semantics that we have today by requiring that either all SILResultInfo are transferring or none are transferring. This also let me swap to @sil_transferring representation.
I did both of these things to fix SIL issues around transferring.
It also ensures that we now properly emit
Our standard conception of suppressible features assumes we should
always suppress the feature if the compiler doesn't support it.
This presumes that there's no harm in suppressing the feature, and
that's a fine assumption for features that are just adding information
or suppressing new diagnostics. Features that are semantically
relevant, maybe even ABI-breaking, are not a good fit for this,
and so instead of reprinting the decl with the feature suppressed,
we just have to hide the decl entirely. The missing middle here
is that it's sometimes useful to be able to adopt a type change
to an existing declaration, and we'd like older compilers to be
able to use the older version of the declaration. Making a type
change this way is, of course, only really acceptable for
@_alwaysEmitIntoClient declarations; but those represent quite a
few declarations that we'd like to be able to refine the types of.
Rather than trying to come up with heuristics based on
@_alwaysEmitIntoClient or other sources of information, this design
just requires the declaration to opt in with a new attribute,
@_allowFeatureSuppress. When a declaration opts in to suppression
for a conditionally-suppressible feature, the printer uses the
suppression serially-print-with-downgraded-options approach;
otherwise it uses the print-only-if-feature-is-available approach.
[region-isolation] Transferring results shouldn't have the following error emitted: "non-sendable type 'NonSendableKlass' returned by implicitly asynchronous call to main actor-isolated function cannot cross actor boundary"
Suppressing this feature doesn't disable the use of new syntax in the
normal way. Instead, it introduces `@rethrows` on the
AsyncIteratorProtocol and AsyncSequence protocols, so that older
compilers can still use the async sequences generated by newer
compilers and standard libraries.
Fixes the rest of rdar://123782658
The newly-introduced associated type `AsyncSequence.Failure` must
always be equivalent to the `Failure` type of the
`AsyncIteratorProtocol`. If the `AsyncSequence` type itself defines a
nested `Failure` type (say, for another purpose), associated type inference
would pick it and reject the `AsyncSequence`, causing a source compatibility
problem.
Work around the issue in two ways. First, always infer the type
witness for `AsyncSequence.Failure` from the type witness for
`AsyncIteratorProtocol.Failure`, so they can't be out of sync. This
means that we'll never even consider a nested `Failure` type in the
`AsyncSequence`-conforming type. This hack only applies prior to Swift 6.
Second, when we have inferred a `Failure` type and there is already
something else called `Failure` within that same nominal type, don't
print the inferred typelias into a module interface because it will
cause a conflict.
Fixes rdar://123543633.
Specifically:
1. Previously when printing we would not put a space after transferring.
2. When a function type has a transferring result, we wouldn't print it when dumping.
Functions that use typed throws _anywhere_ in their signature (including in
closure types) need to be surrounded with `if $TypedThrows` guards in
swiftinterfaces.
Nested types with inverse requirements on generic parameters would
sometimes print incorrectly. We only print the inverses on outer generic
parameters for extensions.
fixes rdar://123281976
Since we no longer remove these attributes from the AttributedTypeRepr,
if we print based on the TypeRepr, we'll print them twice. The best
solution is to only print the attributes based on the inheritance clause
if we're not printing the type based on the TypeRepr.
Fixes rdar://122965951.
The "#if compiler(>=5.3) && $AsyncAwait" checks were necessary for
staging in concurrency in Swift 5.5. At this point, it's safe to assume
that any compiler that tries to read a generated Swift interface file will
support concurrency, so we can stop emitting these guards.
[transferring] Implement transferring result and clean up transferring param support by making transferring a bit on param instead of a ParamSpecifier.
Instead it is a bit on ParamDecl and SILParameterInfo. I preserve the consuming
behavior by making it so that the type checker changes the ParamSpecifier to
ImplicitlyCopyableConsuming if we have a default param specifier and
transferring is set. NOTE: The user can never write ImplicitlyCopyableConsuming.
NOTE: I had to expand the amount of flags that can be stored in ParamDecl so I
stole bits from TypeRepr and added some logic for packing option bits into
TyRepr and DefaultValue.
rdar://121324715
The reason why I am doing this is that I am going to be changing transferring to
not be a true ParamSpecifier. Instead, it is going to be a bit on Param that
changes the default ParamSpecifier used. That being said, I cannot use consuming
for this purpose since consuming today implies no implicit copy semantics, which
we do not want unless the user specifically asks for it by writing consuming.
The name of the `TaskExecutor` protocol was recently changed to remove
underscores after the feature was accepted in Swift Evolution. An implication
of that rename is that the `buildOrdinaryTaskExecutorRef` builtin changed
the type that it expected as the argument. However, the original change
landed in the standard library which as since produced swiftinterfaces
that contain the following inlinable code:
```
@inlinable public init<E>(ordinary executor: __shared E) where E : _Concurrency._TaskExecutor {
#if $BuiltinBuildTaskExecutor
self.executor = Builtin.buildOrdinaryTaskExecutorRef(executor)
#else
fatalError("Swift compiler is incompatible with this SDK version")
#endif
}
```
When a compiler containing the protocol rename attempts to type check the
above inlinable code, it crashes because the builtin is expecting an argument
conforming to `TaskExecutor`, which doesn't exist in this version of the
standard library. The issue is that the current compiler still supports
the `$BuiltinBuildTaskExecutor` feature guard, but the builtin supported
has since changed.
To resolve this issue, we need to stop supporting the `$BuiltinBuildTaskExecutor`
feature guard and introduce a new one that is only supported by compiler versions
that contain the rename. This approach relies on nothing having adopted the
API, otherwise we would need to stage in the rename as a parallel set of APIs,
and only remove the old APIs once nothing is relying on the old _Concurrency
swiftinterfaces.
