xazax.hun added a comment. If we were to refactor this check I wonder if it would make sense to port `evalCall` to `postCall`, so the analyzer engine will conjure the symbol for us. I wonder what @NoQ thinks about the pros and cons of the approaches.
As far as I understand the con of evalCall is that there is only one check that can "win" to do the modelling. Also, it is error prone as everything including binding the return values and invalidating some state needs to be done by hand. If all we need to do is to record some state for the returned symbol, `postCall` should be sufficient. But this can be problematic when we see the body of the function and hence we might not see a returned symbol (but a constant or something else). The name of the patch implies refactoring but some functional changes were also done. Is it possible to separate the functional changes into a separate patch? If it is not a big effort I would prefer that way. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D75163/new/ https://reviews.llvm.org/D75163 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
