erichkeane added a comment. In D31343#1937588 <https://reviews.llvm.org/D31343#1937588>, @aaron.ballman wrote:
> In D31343#1936810 <https://reviews.llvm.org/D31343#1936810>, @Jasmin wrote: > > > Hello John! > > > > I was encouraged by Erich after a talk I had with him and Aaron on IRC to > > contact you about an use case for this plugin. > > > > I wanted to use user-specified/unknown attributes to annotate code and was > > told that they are not propagated through > > the AST and therefore it is not possible at the moment to use them for > > that purpose. Aaron's and Erich's idea was to > > allow kind of no-op attributes in the plugin so that the compiler would > > not issue a warning about the unknown attribute. > > This would be helpful for the user being able to define a list of > > attributes the user knows and expects, so that a compilation > > would not be spammed unnecessarily and misspelled attributes would still > > stand out. > > > > Being able to get the cursor or displayName of the attribute would > > essentially be enough to use it in tooling. > > > > We can use __attribute__((annotate(smth))) at the time being to achieve the > > same goal, but it is much more writing to do > > and also vendor specific. Being able to do the same with attributes would > > give them a real purpose, other than having > > to be accepted and not causing an error. Also they have to be supported by > > the language and we don't have to use > > macros to annotate the code. > > > > To summarize it would be nice to have: > > > > - user supplied unknown attributes to suppress a warning > > - unknown attributes propagated in the AST > > > > I hope I summarized this correctly and could get through the gist of this > > idea. > > > > Looking forward to hearing from you. > > > For reference: the current set of patches John has been working on allow you > to load a plugin to let the frontend parse an attribute with an arbitrary > spelling, but it does not have a way for you to register a new attribute AST > node that gets attached to anything in the AST. Instead, you create an > existing semantic attribute (such as an `AnnotateAttr`) and add that to the > AST. > > I think this is a great request to keep in mind for John or anyone else who > wants to extend this plugin functionality to allow for generating custom > attribute AST nodes (which is of interest for tools like clang static > analyzer or clang tidy plugins that may consume the clang AST). This > functionality would also have to keep the libclang C indexing interface in > mind, as that's another area of the compiler where this functionality would > be useful. Hmm... I wonder if there is value to having these plugin-attributes auto-create a PluginAnnotateAttr or something (some otherwise bikeshedded attribute) for exactly Jasmin's use case. That way the plugin author simply needs to list the possible spellings. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D31343/new/ https://reviews.llvm.org/D31343 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
