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

Fri Jan 14 06:13:14 PST 2022

mboehme added a comment.

Thanks for the feedback! And no worries about the delay -- I know you've got a lot on your plate, and the proposed change is invasive.

To make sure I understand correctly: The issue is that if a `Type` is replaced by an `AttributedType` in places where Clang does not (yet) expect this to happen, this can cause performance regressions or assertions?

The motivation behind making type attributes pluggable is that I'd like to annotate pointers with additional information for use in a memory safety static analysis. The goal here is the same as for the proposal I discussed with you a while ago of extending the `annotate` attribute to types (or possibly adding a new `annotate_type` attribute) on this lengthy mailing list thread (no need to reread it):

https://lists.llvm.org/pipermail/cfe-dev/2021-October/thread.html#69087

In this discussion, I mentioned that I was thinking about making type attributes pluggable too. I eventually realized that this might actually be an easier avenue to pursue than extending `annotate` to types. (As we discussed, there might be cases where the GNU spelling of the `annotate` attribute would associate with a declaration while the C++ spelling would associate with a type, and we hadn't reached a firm conclusion on how best to resolve this. An entirely new pluggable attribute wouldn't have this problem.)

>From your feedback, it sounds as if I should return to my earlier idea of extending `annotate` to types. I wonder though: Wouldn't this suffer from the same problems that you raise above since, again, Clang would see `AttributedType`s in places where it might not expect them?

If the same concerns apply to both of these approaches, do you have any suggestions for alternative ways that I could add annotations to types? Or does this mean that I would have to do the work of making sure that Clang can handle `AttributedType`s in these new places after all?

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114235