[clang] [clang][dataflow] Fully support Environment construction for Stmt analysis. (PR #91616)

Yitzhak Mandelbaum via cfe-commits cfe-commits at lists.llvm.org
Fri May 10 06:21:25 PDT 2024


https://github.com/ymand commented:

I think we can do this without resorting to a pointer union and templating of the initialization functions, but it will take a little refactoring.

First, notice that `stmt` doesn't make sense for the CallStack. The call stack serves two purposes -- to avoid recursion (line 627) and to process the return val (lines 801-811).  Neither of these cases apply for stmts, as you've correctly identified in your modifications to the code (e.g. line 776 in your new version of DataflowEnvironment.cpp)

So, I think its fair to say that CallStack should remain as is. If you're analyzing a Stmt, then you simply don't push onto the call stack. (I'm actually thinking we should not push the starting FunctionDecl onto the call stack either, since it's not called from anywhere, but that's a separate issue...)

That brings us to the second use of the function decl -- initialization. here's where refactoring comes in -- if you look at the init call stack, it's actually doing two things: use the "function decl" stuff (like parameters) and using the body (which is just a stmt). Currently, these are nested. But, I think that, instead, you can refactor to sequence them. Then, for FunctionDecl cases we call both but for Stmts just the second. The way to distinguish I think is just to explicitly store both the FD and the Stmt as separate fields. Then, init will assume there's always a stmt but will check the FD for null. Or, it can rely on the call stack and just look at the top of the call stack, if any.

WDYT?

https://github.com/llvm/llvm-project/pull/91616


More information about the cfe-commits mailing list