-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[ClangImporter] Diagnose bad swift_name attributes better #27924
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
[ClangImporter] Diagnose bad swift_name attributes better #27924
Conversation
Emitting Swift diagnostics in Clang buffers requires making those buffers valid places to put Swift SourceLocs, which means making a mirror of those buffers in the Swift SourceManager. This isn't a copy; instead, any Clang SourceManagers that are involved are kept alive until the importer is torn down. (There might be more than one because of diagnostics emitted during module building.) For a long time we only emitted diagnostics in Clang buffers if the diagnostics came from Clang, but then we added another case for custom Swift names that fail to import. I'm about to add another such diagnostic, so let's formalize this buffer mapping first. No intended functionality change.
1. Set the diagnostic location to where the attribute was written (or to the Clang decl's source, if the attribute came from API notes) 2. Add a note to contact the owners of the framework to make it clear that the client of the framework didn't do anything wrong. rdar://problem/52736145
@swift-ci Please test |
Build failed |
Build failed |
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 like the idea of suggesting to contact the owners of the framework who can actually fix the problem but is there a reason why you did this for this issue in particular? Would other ClangImporter errors benefit from this kind of precision?
What prompted this one is we (Apple) shipped mistakes of this kind at WWDC (oops). What makes the extra note important is that we know there's a custom name—i.e., someone wrote a name explicitly—but that custom name was wrong. There might be a few other places where that's relevant, yeah. |
@swift-ci Please test |
Build failed |
Build failed |
@swift-ci Please test macOS |
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 is a really nice QoI improvement, thank you!
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.
A nice refactoring put to good use.
Set the diagnostic location to where the attribute was written (or to the Clang decl's source, if the attribute came from API notes). This required a bit of reworking in the first commit to make it easier to emit Swift diagnostics in Clang buffers.
Add a note to contact the owners of the framework to make it clear that the client of the framework didn't do anything wrong.
rdar://problem/52736145