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

Reply via email to