-
Notifications
You must be signed in to change notification settings - Fork 10.6k
[cxx-interop] Do not import template type arguments #85379
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
j-hui
merged 6 commits into
swiftlang:main
from
j-hui:dont-import-template-type-arguments-round-2
Nov 11, 2025
+235
−131
Merged
Changes from all commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
b80ab98
[cxx-interop] Check template argument safety in ClangDeclExplicitSafety
j-hui 3255ffb
[cxx-interop] Do not import template type arguments
j-hui 6c997ae
[cxx-interop] Make ClangDeclExplicitSafety request non-recursive
j-hui cbae2fc
[evaluator] hasActiveRequest() considered harmful
j-hui 2b9b507
[cxx-interop] Add a comment about ClangDeclExplicitSafety return Safe…
j-hui 6b3f8c7
[cxx-interop] Rename CxxDeclExplicitSafetyDescriptor -> ClangDeclExpl…
j-hui File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Could we end up visiting the same decl multiple time across different requests?
I wonder if we should also cache the responses explicitly for all the decls that we visited and computed safety for.
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.
That is what we used to do, but caching makes it quite difficult to do this correctly.
Consider:
Upon visual inspection, we can see that
HasUnsafeshould be unsafe because it inherits fromTTake2<PassThru<HasUnsafe>, IsUnsafe>, which is unsafe because its second template type parameter is unsafe. But we might not know that while we're checking the safety of the first template parameter,PassThru<HasUnsafe>.When we look through
PassThru<HasUnsafe>and arrive at its template parameter, we need to break the cycle and assume that safety is unspecified for the time being. We will later discover thatHasUnsafeis actually unsafe via its second template parameter. However, if we are caching intermediate results, then we will incorrectly remember thatPassThru<HasUnsafe>is unspecified, which is incorrect because it has an unsafe template parameter.It's possible to make this work with conditional caching, but it is not clear to me that the added complexity is worth it.
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.
ExplicitSafetycan only beSafe,UnsafeorUnspecified, right? And I assume that if we determine that a type isSafeorUnsafe, we won't later discover it is actually the opposite. So perhaps we could always cache the result unless it isUnspecified?But imo this is not a priority
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 don't think this is algorithmically sound. The current semantics say that a C++ record is explicitly safe if none of its template type arguments, base classes, and fields are not unsafe. In particular, if any of those are considered unspecified due to a cycle, we will erroneously consider the record safe and cache that result.
In fact, I made a mistake in my above explanation.
PassThru<HasUnsafe>would be considered "explicitly" safe despite its template type parameter having unspecified safety.Now, I don't think these semantics are intuitive given that we are saying a type is "explicitly" safe despite some member's safety being unspecified. So we could change that. But I think that warrants a separate discussion.
Uh oh!
There was an error while loading. Please reload this page.
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.
Oh I wasn't aware of that. So, in that case, only
Unsafewould be final.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.
If we don't cache "explicitly" safe requests, then we do lose out on significant caching opportunities, because we wouldn't cache top-level requests that return safe. And those can be the most expensive to compute, i.e., what we would want to cache the most, because determining safety requires visiting all template params, base classes, and fields (whereas unsafety can short-circuit).
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.
Makes sense. But those are getting cached right?
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.
Which are you referring to when you say "those"?
For this PR, we are still caching "root" requests, i.e., the types directly used in Swift programs.