This is an archive of the discontinued LLVM Phabricator instance.

Refactoring attribute subject diagnostics
AbandonedPublic

Authored by aaron.ballman on Apr 4 2016, 11:37 AM.

Details

Summary

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.

Diff Detail

Event Timeline

aaron.ballman retitled this revision from to Refactoring attribute subject diagnostics.
aaron.ballman updated this object.
aaron.ballman added reviewers: rsmith, doug.gregor.
aaron.ballman added a subscriber: cfe-commits.
rsmith edited edge metadata.Apr 22 2016, 4:54 PM

I think this is a reasonable direction. I'd like to see some kind of %list form added to our diagnostics system, but I don't mind whether that happens before or after this change.

(I'd also prefer to use singular forms in the various subject names, but that seems to create problems with the presence/absence of "a" / "an". If you see a way to make that work, we should consider it, but otherwise don't worry about it.)

I had the chance to finalize this long-standing review by fixing up the remaining test cases and removing the unused enumerators from AttributeList.h. I've commit in r319002 (but cannot close the review because the "Accept" didn't happen).

aaron.ballman abandoned this revision.Dec 20 2017, 1:26 PM

Closing this via "abandon" so that Richard doesn't have to accept it in order for me to close it. It's already been committed.