I recommend against using clang_analyzer_eval in user docs. Users aren't expected to know what it is.
Nitpick: the program doesn't become ill-formed just because the user has turned off the checker. Maybe it's better to say that exploring an execution path that already contains undefined behavior is not valuable, or something along those lines(?)
I think it would be useful for the user to see one example per constraint type that this checker supports.
It would be also nice to add a section "Limitations".
Describe there well known false positive cases or limitations in the bug diagnostics that limits understandability.
This section would be useful for users to understand and help identifying cases that are known false positives and for the developers to know how to improve this checker. I remember many cases when we had to test multiple times "why a checker is in alpha", because we forgot about it. I think it is best to document it.
- Describe the different kind of constraints and limitations
- Some rewording
Ok, I've changed to have an infeasible branch condition and below that an unreported div zero warning demonstrates the same.
Ok, I've changed the wording.
Ok, I've added a few paragraphs to describe these things.