This is an archive of the discontinued LLVM Phabricator instance.

Test ExprEngine handling of unknown values
Needs ReviewPublic

Authored by danielmarjamaki on Oct 18 2016, 7:23 AM.

Details

Reviewers
dcoughlin
Summary

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.

Diff Detail

Repository
rL LLVM

Event Timeline

danielmarjamaki retitled this revision from to Test ExprEngine handling of unknown values.
danielmarjamaki updated this object.
danielmarjamaki added a reviewer: dcoughlin.
danielmarjamaki set the repository for this revision to rL LLVM.
danielmarjamaki added subscribers: zaks.anna, NoQ.
dcoughlin edited edge metadata.Oct 18 2016, 9:02 AM

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.

NoQ added inline comments.Oct 18 2016, 9:04 AM
test/Analysis/func.c
46

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.

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.

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.

Thanks! That sounds excellent to me.