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
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
