-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[cxx-interop] Import attributes on inherited C++ methods #59022
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
Conversation
|
||
// CHECK: struct NonTrivial { | ||
// CHECK-NEXT: init() | ||
// CHECK-NEXT: @discardableResult |
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.
Seems like we're getting a lot of @discardableResult
attrs when the base class' member didn't have that attribute. Is it possible that the base class had the attribute but it was false (so it didn't get printed)? Or do you have any idea what's going on 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.
I think clang importer attaches @discardableResult
to all non-void methods that aren't annotated with __attribute__((warn_unused_result))
(see lib/ClangImporter/ImportDecl.cpp:9247
). The reason they suddenly showed up in the test, is because I added the -print-implicit-attrs
to check for attributes that are imported as implicit
by the clang importer (like @available
).
In order to make the test less cluttered, we could switch to using CHECK
so we can ignore the lines with @discardableResult
. Or I could add a new test for inherited attributes. What do you think?
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.
Ah, I see now. Thanks for explaining. Make sense. This LGTM.
break; | ||
} | ||
case DAK_DiscardableResult: { | ||
attrs.add(new (context) DiscardableResultAttr(true)); |
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'm thinking this might not always be true
, maybe that's why we're seeing all the attrs in the test below. But I don't know.
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 decided to always inherit the attributes as implicit
because we also inherit methods as implicit
. Do you think that makes sense?
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.
Yeah, I see now. Sounds good.
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.
This looks really great. Other than my concern about the tests, I don't see any issues.
Thank you for the continued, high-quality patches!
@swift-ci please test. |
@egorzhdan @skrtks OK for me to merge this? |
No objections from my side 👍 |
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.
Looks good, thanks!
We now copy the
DeclAttributes
that are created when mapping Clang attributes to Swift attributes.Fixes #58460