Skip to content

[c++-interop] For failed imports in ClangImporter, cache them regardless. #41173

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

Conversation

plotfi
Copy link
Contributor

@plotfi plotfi commented Feb 3, 2022

As per SR-14137 this caches entries in ImportedDecls even when the
import failed. The use of Optional<NullablePtr> is employed here
as a better way to track this than a raw nullptr.

Also have to mention I did this based on Thomas's PR #36747.

This in theory should help us better handle complex templates and
dependant types.

@plotfi
Copy link
Contributor Author

plotfi commented Feb 3, 2022

@zoecarver @hyp @CodaFi

@zoecarver
Copy link
Contributor

Storing a Optional<NullablePtr> in the map of imported decls doesn't make sense. That already has two failures modes: 1) does the key exists? 2) Is the value null?

What you want is to return an Optional<NullablePtr> from importDeclCached. That way you can communicate both: 1) is there a cached thing here and 2) is that thing null?

I think you can just take Thomas' patch as-is and try to land it. IIRC there were some test failures, so the work in landing this is just debugging the test failures and landing it.

@plotfi plotfi force-pushed the cxx-interop-cache-failed-imports-plotfi branch from 61e2ddb to 8c8a71d Compare February 3, 2022 22:05
@plotfi
Copy link
Contributor Author

plotfi commented Feb 3, 2022

What you want is to return an Optional<NullablePtr> from importDeclCached. That way you can communicate both: 1) is there a cached thing here and 2) is that thing null?

Updated patch, but no optionals at all. I can update importDeclCached to provide a tri-state through Optional<Decl *> where None means nothing was found and nullptr/non-nullptr means it either found a cached import-failure or a succeeded imported decl. IIRC Thomas' patch did not do this (it just returns None if there was a cached nullptr), which is why I think this confused me. I'll ping this PR once I rerun the test suite on this newest version.

@plotfi
Copy link
Contributor Author

plotfi commented Feb 4, 2022

Storing a Optional<NullablePtr> in the map of imported decls doesn't make sense. That already has two failures modes: 1) does the key exists? 2) Is the value null?

What you want is to return an Optional<NullablePtr> from importDeclCached. That way you can communicate both: 1) is there a cached thing here and 2) is that thing null?

I think you can just take Thomas' patch as-is and try to land it. IIRC there were some test failures, so the work in landing this is just debugging the test failures and landing it.

Updated to provide the additional information about prior import failures from importDeclCached. I ran a ninja check-swift and I don't see any additional test failures.

auto cached = importDeclCached(contextDecl, version, useCanonicalDecl);
if (cached.hasValue() && cached.getValue()) {
return cached.getValue();
} else if (cached.hasValue()) {
Copy link
Contributor

Choose a reason for hiding this comment

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

same

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ClangImporter/attr-swift_name.swift fails if we return null from here because the diagnostics code for swift_name_circular_context_import doesn't get hit to append the warning+notes:

/Users/plotfi/local/S/swift/test/ClangImporter/Inputs/custom-modules/ObjCIRExtras.h:78:52: warning: cycle detected while resolving 'MutuallyCircularNameA' in swift_name attribute for 'MutuallyCircularNameB'
SWIFT_NAME(MutuallyCircularNameA.Inner) @interface MutuallyCircularNameB : NSObject @end

/Users/plotfi/local/S/swift/test/ClangImporter/Inputs/custom-modules/ObjCIRExtras.h:77:52: note: while resolving 'MutuallyCircularNameB' in swift_name attribute for 'MutuallyCircularNameA'
SWIFT_NAME(MutuallyCircularNameB.Inner) @interface MutuallyCircularNameA : NSObject @end

/Users/plotfi/local/S/swift/test/ClangImporter/Inputs/custom-modules/ObjCIRExtras.h:78:52: note: please report this issue to the owners of 'ObjCIRExtras'
SWIFT_NAME(MutuallyCircularNameA.Inner) @interface MutuallyCircularNameB : NSObject @end

Since this function will return nullptr from this point regardless, do we want to bail before emitting these warnings?

@zoecarver
Copy link
Contributor

Updated patch, but no optionals at all. I can update importDeclCached to provide a tri-state through Optional<Decl *> where None means nothing was found and nullptr/non-nullptr means it either found a cached import-failure or a succeeded imported decl. IIRC Thomas' patch did not do this (it just returns None if there was a cached nullptr), which is why I think this confused me. I'll ping this PR once I rerun the test suite on this newest version.

Yeah makes sense. In this case, you can return Optional.some(nullptr) when we've cached a nullptr. Make sense?

@zoecarver
Copy link
Contributor

This looks good, though. Thanks again, Puyan!

@plotfi plotfi force-pushed the cxx-interop-cache-failed-imports-plotfi branch 2 times, most recently from 4d0401e to 69ace9b Compare February 7, 2022 06:34
@plotfi
Copy link
Contributor Author

plotfi commented Feb 7, 2022

@zoecarver How does this look? Do you approve of the test case modification? From debugging the flow of the importer with the nullptr caching I believe the change in number of swift_name_circular_context_import warnings is due to the caching.

@plotfi
Copy link
Contributor Author

plotfi commented Feb 9, 2022

@zoecarver Do you think this patch needs more work? I've done some investigation on the swift_name_circular_context_import warnings and I am not sure the exact same ordering of warnings can be printed out with the added caching.

@@ -3417,7 +3417,8 @@ namespace {
auto alreadyImportedResult =
Impl.ImportedDecls.find({decl->getCanonicalDecl(), getVersion()});
if (alreadyImportedResult != Impl.ImportedDecls.end())
return alreadyImportedResult->second;
if (alreadyImportedResult->second)
return alreadyImportedResult->second;
Copy link
Contributor

Choose a reason for hiding this comment

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

We can't return nullptr here?

Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe we can re-factor this to use Impl.importDeclCached?

@zoecarver
Copy link
Contributor

Do you approve of the test case modification?

I'll take a closer look, but it seems fine to me.

@zoecarver
Copy link
Contributor

@swift-ci please test.

@zoecarver
Copy link
Contributor

By the way this patch looks great. Seems like it doesn't touch most visitors which is awesome!

Thanks again for working on it.

@plotfi plotfi force-pushed the cxx-interop-cache-failed-imports-plotfi branch 2 times, most recently from 691459d to f6c3181 Compare February 19, 2022 10:00
@plotfi
Copy link
Contributor Author

plotfi commented Feb 19, 2022

By the way this patch looks great. Seems like it doesn't touch most visitors which is awesome!

Thanks again for working on it.

@zoecarver I addressed your comments. For some of them I just altered isAcceptableResult to do the thing that makes most sense when a nullptr entry is found (if its not an AccessorDecl return false).

…ess.

As per SR-14137 this caches entries in ImportedDecls even when the
import failed.

Also have to mention I did this based on Thomas's PR swiftlang#36747.

This should help us better handle complex templates and dependant types.
@plotfi plotfi force-pushed the cxx-interop-cache-failed-imports-plotfi branch from f6c3181 to 9faff45 Compare March 9, 2022 23:13
@drodriguez
Copy link
Contributor

@swift-ci please smoke test

@drodriguez
Copy link
Contributor

@swift-ci please test Linux platform

@plotfi
Copy link
Contributor Author

plotfi commented Mar 10, 2022

@hyp @zoecarver Tests passing, ready to merge unless you all have more review comments.

Copy link
Contributor

@hyp hyp left a comment

Choose a reason for hiding this comment

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

LGTM, thanks

@drodriguez drodriguez merged commit 09cdd36 into swiftlang:main Mar 10, 2022
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.

4 participants