[cfe-dev] EvaluateWithSubstitution Usage

[Anthony Burzillo (BLOOMBERG/ 731 LEX) via cfe-dev]

Hello fellow clang-ers,

I am looking to evaluate expressions with substitution, but I can't seem to get clang::Expr's EvaluateWithSubstitution to work correctly.

Let me set up this question. Consider the following code...

    bool a = false;

    if (a) {
      std::cout << "HERE" << std::endl;
    }

    a = true;

Suppose that I am trying to remove code paths that cannot possibly be reached. So in this case I have a matcher that will pick out the condition of the if statement as a clang::Expr. I would like to determine whether or not this clang::Expr can be evaluated to true or false.

Suppose I am able to query the values of all of the variables that have deterministic values at the beginning of the condition. So my first approach was to construct a dummy function, where the arguments are named the same
and have the same types as these deterministic variables, for example

    bool dummy_fn(bool a)

and then construct a vector of arguments, i.e. { false }, to apply to the function. Then I would use the condition's EvaluateWithSubstitution method, passing in my dummy function and the corresponding arguments.

Unfortunately this approach does not seem to work, even with such a seemingly trivial example.

I have a feeling that the issue may be that the clang::DeclRefExpr of the 'a' within the condition's clang::Expr is pointing to a clang::Decl that is not the same as the parameter of my dummy function, but I'm not sure of the best way to fix this (especially when the conditions become much more complicated and involving multiple clang::DeclRefExpr's).

So my question is two-fold:
    (1) Am I approaching this problem in the most "clang-y" way, or is there
        some other approach I should be using that would work better?
    (2) In your opinion is the issue with the above approach as I described,
        i.e. that the clang::Decl of 'a' is not the same as the parameter 'a's,
        or is there something else that I may have missed?

Thank you very much for your help!
Anthony Burzillo <aburzillo at bloomberg.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190416/8ec184c8/attachment.html>