Skip to content

[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

Merged
merged 4 commits into from
Oct 30, 2019

Conversation

jrose-apple
Copy link
Contributor

  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). This required a bit of reworking in the first commit to make it easier to emit Swift diagnostics in Clang buffers.

  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

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
@jrose-apple
Copy link
Contributor Author

@swift-ci Please test

@swift-ci
Copy link
Contributor

Build failed
Swift Test OS X Platform
Git Sha - 8168669

@swift-ci
Copy link
Contributor

Build failed
Swift Test Linux Platform
Git Sha - 8168669

Copy link
Contributor

@xymus xymus left a 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?

@jrose-apple
Copy link
Contributor Author

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.

@jrose-apple
Copy link
Contributor Author

@swift-ci Please test

@swift-ci
Copy link
Contributor

Build failed
Swift Test Linux Platform
Git Sha - 8168669

@swift-ci
Copy link
Contributor

Build failed
Swift Test OS X Platform
Git Sha - 8168669

@jrose-apple
Copy link
Contributor Author

@swift-ci Please test macOS

Copy link
Member

@DougGregor DougGregor left a 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!

Copy link
Contributor

@beccadax beccadax left a 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.

@jrose-apple jrose-apple merged commit 37bb356 into swiftlang:master Oct 30, 2019
@jrose-apple jrose-apple deleted the attribute-attribution branch October 30, 2019 16:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants