[PATCH] D114235: [clang] Extend ParsedAttr to allow custom handling for type attributes

[Martin Böhme via Phabricator via cfe-commits]

mboehme added a comment.

In D114235#3340412 <https://reviews.llvm.org/D114235#3340412>, @erichkeane wrote:

> In D114235#3340369 <https://reviews.llvm.org/D114235#3340369>, @mboehme wrote:
>
>> In D114235#3244054 <https://reviews.llvm.org/D114235#3244054>, @aaron.ballman wrote:
>>
>>> so there could likely be places that need updating to look "through" the attributed type. But unlike with arbitrary plugins, the number of places is hopefully more reasonable.
>>
>> IIUC, this already happens to some extent for other type attributes -- correct? For example, the nullability attributes (`_Nonnull` and the like). However, these can only be applied to pointer types (e.g. `int * _Nonnull ptr`), while an `annotate_type` attribute could also be applied to other types (e.g. `int [[clang::annotate_type("foo")]] i`). Is this an example of the places you're thinking of that would need to be touched?
>
> _Nonnull has exactly the problems we are talking about; it is put on the attributed-type, which end up getting lost in canonicalization just about immediately.

For my purposes, it would be fine, and maybe even desirable, for the proposed `annotate_type` to have the same limitations as `_Nonnull`.

Are you saying that a) this would not be acceptable for a more general-purpose attribute such as a putative `annotate_type`, or even that b) the behavior of `_Nonnull` itself is seen as undesirable and should be changed if possible?

> This is going to be an incredibly heavy lift, I just don't see how you can make it 'last' through the type system.  For example:
>
>   template<typename T>
>   struct S {
>     using my_type = T;
>   };
>   
>   using my_attr_type = int [[annotated_type("asdf")]];
>   
>   S<int>::my_type;
>   S<my_attr_type>::my_type; <-- will have lost the attribute already, since you want them to behave as the same type.
>   std::is_same<int, my_attr_type>::value; // Do you want this to be true?

Yes.

>   std::is_same<S<int>, S<my_attr_type>::value; // What about this one?

Yes.

Both of these are what the `_Nullable` attribute does today (godbolt <https://godbolt.org/z/Tv3GeWefh>), and I would be happy for the proposed `annotate_type` attribute to have the same semantics.

> This problem ends up being generally intractable as far as I can imagine.  The C++ language doesn't have the idea of strong-typedefs, a type is just the type.  You can't have 1 instance of the type have an attribute, and others not without them being DIFFERENT types.  So you'd have to have some level of AnnotatedType in the type system that does its best to ACT like its underlying type (at great development cost to make sure it doesn't get lost, basically everywhere), but actually isn't.  For example, it would have to end up failing the 2nd `is_same` above, which, IMO, would be language breaking unless the 1st `is_same` ALSO stopped being true.

As noted above, this isn't actually what I'm trying to achieve.

Some colleagues and I are currently preparing an RFC for the specific use case we'd like to use the proposed `annotate_type` attribute for. That use case might give more context to the discussion. If you think it would help to put this discussion on hold until we've written up and posted the RFC, I'd be happy to do that. If you have any additional comments right now, I'd be happy to hear those too of course!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114235