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.
Otherwise, we can't successfully dry-run a toolchain on darwin.
I added an option enable-extract-symbol-dry-run-test that can be set to restore
the previous behavior and updating the BuildSystem unit tests that depend on
that behavior to pass that flag.
It makes sense to just set this here since we aren't testing that functionality
and enables us to test this if we aren't using one of the specified Xcodes
(which can be useful).
Detect situations when type of a declaration hasn't been resolved yet
(one-way constraints would use a type variable to represent a type of IUO pattern),
and use additional type variable and a constraint to represent an
object type of a future optional type.
Resolves: SR-14893
Resolves: rdar://80271666
For clang symbols marked with SPI_AVAILABLE, we add SPIAccessControlAttr to them so they will be
considered as SPIs in the AST. To be able to use all these symbols, we also add an implicit SPI import
statement for all clang modules. All clang SPIs belong to the same SPI group named "OBJC_DEFUALT_SPI_GROUP" because clang
currently doesn't support custom SPI group.
rdar://73902734
This is where I am going to put the stage 2 swift. The reason why I need to do
this is that I need libdispatch, foundation, etc on Linux to use the stage2
compiler.
The key thing here is that by using this builder, I am going to be able to split
the build-script-impl pipeline in two and put in a build-script pipeline in
between. This is needed so that on Linux, we can build the stage 2 compiler
before we build any of the build-script-impl libraries that depend on having a
swift compiler.
This should be an NFCI change. I am relying on our build system unit tests to
ensure that I am not changing any real behavior.
Add three new flags, '--skip-clean-libdispatch', '--skip-clean-foundation', and
'--skip-clean-xctest', that leave the previous builds of those products in place.
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
7856f2d83d only partially skipped writing
out destructors when they were invalid, ie. it skipped writing the decl
itself but not the records common to all decls. This would cause any
records on the destructor to be applied on the next serialized decl.
Make sure to skip serializing anything to do with the destructor when
it's invalid and does not have a class context.
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
