Skip to content

Non-copyable generics fixes #71241

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

Merged
merged 21 commits into from
Feb 1, 2024
Merged

Conversation

slavapestov
Copy link
Contributor

@slavapestov slavapestov commented Jan 30, 2024

This fixes some validation test failures when non-copyable generics are enabled. Should be NFC otherwise.

@slavapestov slavapestov force-pushed the ncgenerics-fixes branch 2 times, most recently from 369fae7 to a88a144 Compare January 30, 2024 20:24
@slavapestov
Copy link
Contributor Author

@swift-ci Please smoke test

@slavapestov
Copy link
Contributor Author

@swift-ci Please smoke test

@slavapestov
Copy link
Contributor Author

@swift-ci Please test source compatibility

Comment on lines +2958 to +2962
// Force creation of the generic signature.
(void) ED->getGenericSignature();
dumpGenericSignature(Ctx, ED);

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm curious why we have to do this now.

Copy link
Contributor Author

@slavapestov slavapestov Feb 1, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We force certain requests in TypeCheckDeclPrimary just to ensure diagnostics are emitted before we go on to SILGen. (This isn't new, I just moved some code around so that the -debug-generic-signature behavior happens here instead of in TypeCheckGeneric.cpp.)

Copy link
Member

@ahoppen ahoppen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only reviewed the code completion parts.

Comment on lines +272 to +274
LLVM_DEBUG(llvm::dbgs() << "Adding conformed protocol "
<< Conformance->getProtocol()->getName()
<< "\n";);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are these debug statements intentionally left?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They're only active when you run with -Xllvm -debug-only=CodeCompletionResultType

@@ -22,6 +22,9 @@ using namespace swift;
using namespace ide;
using TypeRelation = CodeCompletionResultTypeRelation;

#define DEBUG_TYPE "CodeCompletionResultType"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Stupid question: What is DEBUG_TYPE used for?

SmallVector<const USRBasedType *, 2> Supertypes;
;
if (auto Nominal = Ty->getAnyNominal()) {
if (auto *Proto = dyn_cast<ProtocolDecl>(Nominal)) {
Proto->walkInheritedProtocols([&](ProtocolDecl *inherited) {
if (Proto != inherited &&
!inherited->isSpecificProtocol(KnownProtocolKind::Sendable)) {
!inherited->isSpecificProtocol(KnownProtocolKind::Sendable) &&
!inherited->getInvertibleProtocolKind()) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I’m not sure how the inverted protocols are modeled in the AST but shouldn’t we check if the specific conformance is inverted (ie. has ~) instead of checking whether the protocol is invertible?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're just skipping these protocols entirely here because we get the wrong USRs for their ProtocolDecls. Once the USR mangling is fixed we can remove this hack.

Comment on lines +268 to +269
// FIXME: Copyable and Escapable conformances are skipped because the
// USR mangling produces the type 'Any' for the protocol type.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why does it produce Any for the protocol name?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because we need to fix the mangling.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, I see. Thanks for the clarification. Is the name mangling something we are planning to fix in the short term?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, because we need to distinguish Any (which is now formally <Self where Self: Copyable, Self: Escapable> but must mangle as before) from any ~Copyable (<Self where Self: Escapable>, which needs a new mangling invented) and any ~Escapable (<Self where Self: Copyable>, ditto). Right now we simply strip out Copyable and Escapable from existentials before mangling, which is not correct.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, great 👍🏽

We want extensions to introduce default Copyable/Escapable just like
other generic contexts, so that once Optional adopts ~Copyable,
an `extension Optional` actually adds `Wrapped: Copyable` by default.
@slavapestov
Copy link
Contributor Author

@swift-ci Please smoke test

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants