[PATCH] D18768: Refactoring attribute subject diagnostics

Aaron Ballman via cfe-commits cfe-commits at lists.llvm.org
Mon Apr 4 11:37:04 PDT 2016

aaron.ballman created this revision.
aaron.ballman added reviewers: rsmith, doug.gregor.
aaron.ballman added a subscriber: cfe-commits.

Currently, attribute subject lists attempt to automatically determine what diagnostic to emit when the attribute does not appertain to a given declaration. It does so by the attribute tablegen emitter looking at the subject list and attempting to match it up with a viable enumerator in AttributeList.h. This approach is starting to show signs of wear now that we are getting more complex attribute subject lists. It also runs into problems where users don't want to add a one-off enumerator and instead use an existing close-but-not-quite-accurate diagnostic.

This patch attempts to improve the situation by removing the need for the enumeration and complex selection logic in the diagnostics tablegen. Instead, each declaration and statement node tablegen description includes a comma-separated list of subjects for diagnostics that the attribute tablegen emitter uses to create a single string to pass to a new diagnostic. This approach is not ideal -- ideally we would have a "list" notion for the diagnostics engine that could handle properly formatting a list so that it handles multiple elements for us. However, I think my current approach is an incremental improvement that gets us a step closer to being able to use such a list mechanism were it to be implemented in the future.

Before I correct all of the test cases for minor diagnostic differences, I wanted to point out those differences explicitly:

* The following were renamed to reduce confusion:
  * methods -> Objective-C methods
  * interfaces -> Objective-C interfaces
  * protocols -> Objective-C protocols
  * fields -> non-static data members
  * types -> typedefs
* We used to consider CXXRecordDecl to only be "classes" while RecordDecl was "struct, union, or class"; we would drop the "or class" part when not compiling in C++ mode. Now that we've switched to a string literal, dropping (or adding) "classes" is more challenging and so RecordDecl always reports "classes" under the assumption that it won't be overly confusing to C users. I am also banking on there being more C++ users than C users, but an alternative may be to drop "classes" from RecordDecl under the assumption that users understand "struct" is the effectively same thing as a "class" in C++.

Note that the actual declarations the attribute appertains to haven't changed, just the spelling of the diagnostics.

If the general approach taken here is reasonable, then I will update the patch with corrected test cases and other polish-related fixes. But since it affects ~30 test cases (due to the updated terminology, consistent use of 'and' instead of 'or', etc), I didn't want to go through the effort unless the patch is going in a reasonable direction.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: D18768.52584.patch
Type: text/x-patch
Size: 28658 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20160404/e3d61a22/attachment-0001.bin>

More information about the cfe-commits mailing list