-
Notifications
You must be signed in to change notification settings - Fork 10.6k
Correct effective context translation for NS_OPTIONS anon C++ enums attempt 2 #62172
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
Correct effective context translation for NS_OPTIONS anon C++ enums attempt 2 #62172
Conversation
|
@swift-ci please smoke test |
Please run the full test suite instead of just |
Yes I will, I'm just trying to run the macOs smoke tests repeatedly since I'm unable to reproduce the failure that caused the revert locally, and it seems to have passed in many many CI runs prior to the revert. https://ci.swift.org/job/swift-PR-macos-smoke-test/4317/. Did this break PR break something a full run of |
|
@swift-ci please test |
Prior to this patch, SwiftLookupTable::translateDeclToContext relied
on the `TypedefNameDeclOrQualifier` field of an anonymous tag decl to
create a name for entry representing an anonymous tag in the lookup
table. This field is not always populated by Clang, it is often
populated only for the purposes of generating a linkage name when the
type is introduced via typedef as follows:
```
typedef enum { option1, option2} MyAnonEnum;
```
The field is not populated for anonymous enums introduced by NS_OPTIONS
with cxx interop enabled. This patch adds a fallback check in
`translateDeclToContext` that if the field is empty, check if the enum
is backed by a typedef that is unavailable in Swift. If that is the
case, use that name for the lookup table entry.
03bcf18 to
5f5bebf
Compare
|
@swift-ci please test |
| @@ -0,0 +1,11 @@ | |||
| // RUN: %empty-directory(%t/cache) | |||
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.
@hyp I think @drodriguez found the issue, these two tests were sharing a module cache and emptying it at the start of the test. If these tests are run concurrently you get weird flaky failures. I've changed %T -> %t to make sure the module cache directories are distinct.
hyp
left a comment
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
|
@swift-ci please test source compatibility |

Second attempt at: 62058