This is a follow-up from https://reviews.llvm.org/D25326
I try to test it as dcoughlin suggested.
https://reviews.llvm.org/D25326#570532
I failed to add expected-warning{{UNKNOWN}} in unreachable-code-path.c but managed to do it in func.c.
Differential D25728
Test ExprEngine handling of unknown values danielmarjamaki on Oct 18 2016, 7:23 AM. Authored by
Details
This is a follow-up from https://reviews.llvm.org/D25326 I try to test it as dcoughlin suggested. I failed to add expected-warning{{UNKNOWN}} in unreachable-code-path.c but managed to do it in func.c.
Diff Detail
Event TimelineComment Actions Why doesn't this work in unreachable-code-path.c? The goal here is to provide a canary (with a comment) that tells whoever changes array modeling that they will need to update the test in unreachable-code-path.c. If the canary is in another file, it is not very helpful. The closer the canary is to the test it is for, the more likely it is that the person updating either the canary or the test will also update its counterpart.
Comment Actions I didn't get the UNKNOWN I expected. Do I need to tweak the command line maybe? I tried to add some debug.ExprInspect but I still didn't get the UNKNOWN. I tried something like this: static int inlineFunction(const int i) { if (table[i] != 0) { } clang_analyzer_eval(table[i] != 0); // expected-warning {{UNKNOWN}} if (table[i] != 0) return 1; return 0; }} I want the test to have two returns that we ensure are not merged. Comment Actions Here is a suggestion. The ultimate goal in D25326 is to test a scenario in which the analyzer returns an UnknownVal. Rather that writing fragile code that currently returns an UnknownVal that but might be improved in the future to do better, why don't we add a ExprInspection-like function 'clang_analyzer_unknown_val()' that that the models as returning an UnknownVal? This expresses the intent of the test much better and is not fragile in the face of analyzer improvements. |
I think this check is not enough. We are not satisfied that the value is not known; we should also know that it's not symbolic either, but a plain UnknownVal. Such test should be possible with clang_analyzer_explain.