[5.9][interop] Ensure an FRT or a pointer to struct/class gets a Swift typ… #65452
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.
…e name for a C++ template parameter
In the follow-up, I should also expand this to cover pointers to builtin types too, but for now lets go with a miminal fix here
(cherry picked from commit 0fff769)
Explanation: Swift type name importer imports C++ template parameters as
_
in cases where it can't provide a good Swift name. This logic did not handle the case where the template parameter was a pointer type, either a pointer to a foreign reference type, or a regular C++ record that's brought in as a value type. This patch expands this logic and ensures that these types are printed clearly, so that the user can see them when code-completing APIs or looking at the module interface print out of an API that uses such a type.Scope: Swift's and C++ interoperability, Clang importer.
Risk: Low. This change only touches on C++ template parameters, which are only reached when C++ interoperability is enabled.
Testing: Swift unit tests.
Reviewer: @zoecarver