jonathan.protzenko added a comment. > I'm hoping we can devise a way to not require the entity being attributed to > be passed when parsing the attribute
That sounds nice. My only concern with this proposal is to make sure this doesn't rule out the interesting use-cases I was mentioning, like the `managed_string` example I presented in the motivation section. These use-cases would need to have some contextual information to perform meaningful parsing. Note that I'm not particularly committed to struct field declarations, one could imagine interesting use-cases with function arguments, such as: void f (int *arr [[ alloc_size(arr) == 8 ]], size_t idx [[ idx <= 4 ]]) But I agree about the parsing problems you mention, and being unable to meaningfully pass a `Declarator` (or anything else) based on incomplete parsing information. Here's a solution that might makes us both happy :), but you'd have to tell me if this is workable. - Upon encountering `[[ attr(X) ]]` where `attr` is a plugin-handled attribute: clang parses `X` as token soup, only caring about finding a matching parenthesis - The complete construct (declaration, type, statement, or whatever the attribute appertains to) is parsed. - Plugin's `diagAppertainsToDecl` gets called (as before). Plugin is free to store in its internal state whatever information from the `Decl` is relevant. - Plugin's `parseAttributePayload` gets called in a state that consumes the token soup (not sure if that's feasible?). The `parseAttributePayload` method does not receive a `Declarator` or anything else. Plugins can rely on the fact that if `diagAppertainsToDecl` returns `true`, `parseAttributePayload` will be called next, and refer to its internal state to fetch whatever information from the `Decl` it needs. Does this stand any chance of working? Bonus question: seeing `diagAppertainsToDecl`, the name of this function led me to believe that for now, plugins could only handle attributes attached to declarations. Is this the case? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D86169/new/ https://reviews.llvm.org/D86169 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits