[PATCH] D86169: Initial support for letting plugins perform custom parsing of attribute arguments.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D86169#2240384 <https://reviews.llvm.org/D86169#2240384>, @jonathan.protzenko wrote:

>> 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.

That should be possible.

> 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

Just to be clear, what you mean is to lex all of the tokens comprising `X` and store them off for later?

> - 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?

This is along the same lines of what I was thinking, but there is one potential snag. Clang layers our library components and Sema should never refer back to the Parser (it doesn't link the library in). Because you have an odd requirement where you need to do further parsing during the semantics stage, you may run into awkwardness from this. Also, you may have to worry about needing this functionality recursively. e.g., `int x [[your_attr(int y [[your_attr(int z;)]];)]];` which could be... interesting.

> 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?

Correct, the plugin system does not yet handle type or statement attributes (it was focusing on declaration attributes first, which are the lion's share of attributes in Clang).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D86169/new/

https://reviews.llvm.org/D86169