Covers a missing case in codable synthesis for enums with argument
payloads that have internal and external labels. When the name of the
var decl is used, the internal name of the parameter becomes the key
instead of the API name. In this case, this causes an invalid reference
to an enum case with the internal name as an argument to be synthesized
in the derived Decodable conformance which (hopefully) crashes
downstream.
rdar://86339848
These fail with -requirement-machine-protocol-signatures=verify because
the GSB produces incorrect output. Enable the requirement machine
unconditionally for these tests, bypassing verification.
A new file test/Generics/same_type_requirements_in_protocol.swift
contains reduced versions of all of the failures, with FileCheck
used to confirm the exact requirement signature output.
Previously, when we reached the maximum nesting level, we changed the current token’s kind to an EOF token. A lot of places in the parser are not set up to expect this token change. The intended workaround was to check whether pushing a structure marker failed (which would change the token kind) and bail out parsing if this happened. This was fragile and caused assertion failures in assert builds.
Instead of changing the current token’s kind, and failing to push the structure marker, let the lexer know that it should cut off lexing, essentially making the input buffer stop at the current position. The parser will continue to consume its current token (`Parser.Tok`) and the next token that’s already lexed in the lexer (`Lexer.NextToken`) before reaching the emulated EOF token. Thus two more tokens are parsed than before, but that shouldn’t make much of a difference.
The concurrency runtime now deploys back to macOS 10.15, iOS 13.0, watchOS 6.0, tvOS 13.0, which corresponds to the 5.1 release of the stdlib.
Adjust macro usages accordingly.
In 1ae317dd88, all the machinery was added
to enable calling ObjC functions that have both async and error
conventions. The handling that was added for matching up arguments and
parameters, however, failed to handle functions that had both foreign
async and foreign error and other arguments. Here, that handling is
fixed.
The fix is in four parts:
- Reverting to a single call to CallSite::emit to emit the formal
params. At this point, the foreign async and/or error params will be
claimed as well.
- Separately counting the async and error parameters in
ParamLowering::claimParams to ensure we get the right parameter
slices.
- Letting ArgEmitter::maybeEmitForeignArgument look for an error
parameter even if it already found an async parameter.
- Letting ArgEmitter::maybeEmitForeignArgument keep looking for foreign
arguments after it finds one.
rdar://80704984
The validation-test suite was incorrectly being run without the
concurrency feature enabled, so the tests were disabled. Now that
they're running, they need fixed availability annotations.
This enabled a gross idiom that should not have been allowed in the first place:
typealias G<T> = Any where T : P
protocol P {}
protocol Q : G<Self> {} // Q inherits from P now!
I'd like to ban this, assuming nothing is actually relying on this behavior.
Returning a null GenericSignature is not the right way to break a cycle,
because then callers have to be careful to handle the case of a null
GenericSignature together with a non-null GenericParamList, for example
in applyGenericArguments().
An even worse problem can occur when a GenericSignatureRequest for a
nested generic declaration requests the signature of the parent context,
which hits a cycle. In this case, we would build a signature where
the first generic parameter did not have depth 0.
This makes the requirement machine upset, so this patch implements a new
strategy to break such cycles. Instead of returning a null
GenericSignature, we build a signature with the correct generic
parameters, but no requirements. The generic parameters can be computed
just by traversing GenericParamLists, which does not trigger more
GenericSignatureRequests, so this should be safe.
When converting an ObjC method type which is being called as async to a
Swift function type, some of the values passed to the ObjC method's
completion handler are converted to return values of the Swift function.
The flag and error parameters, however, if present, are ignored.
When abstracting the result type for the Swift method, the formal type
of the corresponding parameter in the ObjC method's completion handler
is used. Digging out that parameter entails indexing into the
parameters of the completion handler. Previously, the indexing logic
relied on the error appearing before the flag if both appeared before
the value of interest. Here, the indexing is tweaked to check both
special indices for each possible index until the first that matches
neither is found.
rdar://81625544
In the synthesized completion handler that is passed to ObjC methods
that are called as async, the formal type of each argument is the
corresponding parameter of the formal type of the block. The non-error,
non-index arguments need to be prepared so that they can be used to
fulfill the continuation; the lambda which does that preparation for
each such argument takes the formal type of that argument. As such, the
call to that lambda needs to pass the type of the corresponding
parameter of the formal type of the block to that lambda. Doing so
entails skipping over the error and flag parameters if they appear
before some of the non-error, non-index arguments.
Previously, no parameters were skipped over. Consequently, when an
error or flag argument preceded one of the non-error, non-index
arguments, the wrong formal type was passed to the preparation lambda.
Here, that is fixed by passing the correct index. The to-be-used
indices for the formal block parameters are the same as the to-be-used
indices for the lowered block parameters minus one reflecting the fact
that the lowered block always has an initial block_storage parameter as
the first argument which the formal type never has.
rdar://81617749
Previously, the function emitCBridgedToNativeValue handled three
situations around optionals:
- Bridged?, Native?
- Bridged, Native?
- Bridged, Native
Here, handling for the fourth case
- Bridged?, Native
is added.
To enable this, the number of Optional wrappings that the bridged type
has that the native type does not is passed in to the function. Then,
in the portions of the function where actual transformations are done,
the values are unwrapped an appropriate number of times. Mostly that
means force unwrapping N times before doing the transformation. In the
case of types that conform to _ObjectiveCBridgeable, however, it means
force unwrapping the value N-1 times after doing the transformation
because _ObjectiveCBridgeable._unconditionallyBridgeFromObjectiveC
performs one layer of unwrapping itself.
rdar://81590807
Previously, SILGen assumed that a foreign function could either have a
foreign async convention or a foreign error convention, but if it had
both, the error would be subsumed into the completion. That resulted in
failures to emit code for async calls of functions like
```
- (BOOL)minimalWithError:(NSError* _Nullable*)error
completionHandler:(void (^ _Nonnull)(void))completionHandler;
```
Here, SILGen gains the ability to emit such functions. To enable that,
a few changes were required when both conventions are present:
- a separate argument for each convention is used
- the ResultPlan is a ForeignErrorResultPlan nesting a
ForeignAsyncResultPlan
- the continuation is always of the form UnsafeContinuation<_, Error>
regardless of whether the completion handler takes an error
- the foreign error block fills the continuation with the error that was
passed by reference out of the ObjC method call
- the foreign error block branches to the block containing the await
instruction
rdar://80704984
Stopped validation-test/compiler_crashers_2_fixed/rdar79383990.swift
from trying to call -[NSBackgroundActivityScheduler scheduleWithBlock:]
async--that method is now annotated NS_SWIFT_DISABLE_ASYNC.
Previously, AbstractionPattern::getOpaque() was used for async
continuations. That was problematic for functions like
```objc
- (void)performVoid2VoidWithCompletion:(void (^ _Nonnull)(void (^ _Nonnull)(void)))completion;
```
whose completion takes a closure. Doing so resulted in attempting to
build a block to func thunk where one of the functions had an out
parameter.
Instead, use the AbstractionPattern(ty).
rdar://79383990
The solver's simplifyType() can produce a DependentMemberType with a
concrete or archetype base, if that associated type could not be
resolved during associated type inference.
mapTypeOutOfContext() could assert when given a type that violates
invariants in this manner. Instead, let's directly call subst() here,
providing a conformance lookup function (which will probably end up
returning ErrorTypes).
Fixes https://bugs.swift.org/browse/SR-14672 / rdar://problem/78626943.
Let's make use of a newly added "disable for performance" flag to
allow solver to consider overload choices where the only issue is
missing one or more labels - this makes it for a much better
diagnostic experience without any performance impact for valid code.
