-
Notifications
You must be signed in to change notification settings - Fork 10.6k
SILGen: fix cast of Optional<any Sendable> -> Optional<Any> #85472
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -20,6 +20,7 @@ | |
| #include "swift/AST/Decl.h" | ||
| #include "swift/AST/DiagnosticEngine.h" | ||
| #include "swift/AST/DiagnosticsSIL.h" | ||
| #include "swift/AST/ExistentialLayout.h" | ||
| #include "swift/AST/Expr.h" | ||
| #include "swift/AST/FileUnit.h" | ||
| #include "swift/AST/GenericEnvironment.h" | ||
|
|
@@ -43,8 +44,8 @@ | |
| #include "swift/SIL/SILInstruction.h" | ||
| #include "swift/SIL/SILModule.h" | ||
| #include "swift/SIL/Test.h" | ||
| #include "clang/AST/Type.h" | ||
| #include "clang/AST/Decl.h" | ||
| #include "clang/AST/Type.h" | ||
| #include "llvm/Support/Compiler.h" | ||
| #include "llvm/Support/Debug.h" | ||
|
|
||
|
|
@@ -4914,6 +4915,17 @@ TypeConverter::checkForABIDifferences(SILModule &M, | |
| } | ||
| } | ||
|
|
||
| // Existentials are ABI-compatible if their layouts are compatible. | ||
| if (!optionalityChange) { | ||
| auto ct1 = type1.getASTType(); | ||
| auto ct2 = type2.getASTType(); | ||
| if (ct1->isExistentialType() && ct2->isExistentialType() && | ||
| ct1->getExistentialLayout().isABICompatibleWith( | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If dropping marker protocols is the correct fix here, I would prefer you used the existing
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I second this, we have a tendency to add a lot of things that essentially do the same thing but with slight differences and it's sometimes really hard to use these APIs.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Although perhaps we should sink it down to TypeBase from ProtocolCompositionType, so that it can properly handle a single ProtocolType that's a marker protocol |
||
| ct2->getExistentialLayout())) { | ||
| return ABIDifference::CompatibleRepresentation; | ||
| } | ||
| } | ||
|
|
||
| // Tuple types are ABI-compatible if their elements are. | ||
| if (!optionalityChange) { | ||
| if (auto tuple1 = type1.getAs<TupleType>()) { | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -417,19 +417,15 @@ adjustForConditionalCheckedCastOperand(SILLocation loc, ManagedValue src, | |
| if (!hasAbstraction && (!requiresAddress || src.getType().isAddress())) | ||
| return src; | ||
|
|
||
| TemporaryInitializationPtr init; | ||
| if (requiresAddress) { | ||
| init = SGF.emitTemporary(loc, srcAbstractTL); | ||
|
|
||
| if (hasAbstraction) | ||
| src = SGF.emitSubstToOrigValue(loc, src, abstraction, sourceType); | ||
|
|
||
| // Okay, if all we need to do is drop the value in an address, | ||
| // this is easy. | ||
| SGF.B.emitStoreValueOperation(loc, src.forward(SGF), init->getAddress(), | ||
| StoreOwnershipQualifier::Init); | ||
| init->finishInitialization(SGF); | ||
| return init->getManagedAddress(); | ||
| if (src.getType().isAddress()) | ||
| return src; | ||
|
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Looks like these changes fix |
||
|
|
||
| return src.materialize(SGF, loc); | ||
| } | ||
|
|
||
| assert(hasAbstraction); | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I follow. There are other situations where two existential types are ABI compatible but not the same type in the compiler, for example
P & AnyObjectvsP & Cfor an arbitrary classC. Does the compiler also enter an infinite loop in that case?