[clang] [clang-tools-extra] [llvm] User-defined annotations for clang-tidy analysis POC (PR #195054)

[Valentyn Yukhymenko via cfe-commits]

BaLiKfromUA wrote:

@unterumarmung thanks for the detailed feedback!

I really like your use cases, especially the `variant`-like type example.

JFYI, I’m planning to present the initial version of this proposal at the next Static Analysis WG meeting, which is scheduled for June 16th, Tuesday next week. After that discussion, we aim to revisit the RFC content, improve the proposed design, and potentially address some of the open questions and concerns.

> So I think the common pattern is: expose analysis-relevant facts directly. That seems more reusable than saying “this API should be analyzed as that other API.”

I hope to find time before the meeting to incorporate your feedback regarding a more generalized design. At a minimum, I will use your examples as additional motivation and as possible future extensions.

> One thing I would like the PoC to spell out is how partial or invalid annotations behave. For example, if a method is annotated as test_state("engaged") but does not return something contextually convertible to bool, or if a method has conflicting state annotations, should Sema diagnose it, should the analyzer warn, or should the annotation be ignored? I think avoiding silent degradation is important if these annotations are meant to become part of library headers.

I agree with this point. We should be explicit and emit diagnostics when annotations are misconfigured on the user side.


https://github.com/llvm/llvm-project/pull/195054