-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[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
[c++-interop] For failed imports in ClangImporter, cache them regardless. #41173
Conversation
Storing a What you want is to return an 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. |
61e2ddb
to
8c8a71d
Compare
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. |
Updated to provide the additional information about prior import failures from |
lib/ClangImporter/ImportDecl.cpp
Outdated
auto cached = importDeclCached(contextDecl, version, useCanonicalDecl); | ||
if (cached.hasValue() && cached.getValue()) { | ||
return cached.getValue(); | ||
} else if (cached.hasValue()) { |
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.
same
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.
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?
Yeah makes sense. In this case, you can return |
This looks good, though. Thanks again, Puyan! |
4d0401e
to
69ace9b
Compare
@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. |
@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. |
lib/ClangImporter/ImportDecl.cpp
Outdated
@@ -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; |
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.
We can't return nullptr here?
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.
Maybe we can re-factor this to use Impl.importDeclCached
?
I'll take a closer look, but it seems fine to me. |
@swift-ci please test. |
By the way this patch looks great. Seems like it doesn't touch most visitors which is awesome! Thanks again for working on it. |
691459d
to
f6c3181
Compare
@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.
f6c3181
to
9faff45
Compare
@swift-ci please smoke test |
@swift-ci please test Linux platform |
@hyp @zoecarver Tests passing, ready to merge unless you all have more review comments. |
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.
LGTM, thanks
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.