This is an archive of the discontinued LLVM Phabricator instance.

[analyzer] NFC: Merge object construction related state traits into one.
ClosedPublic

Authored by NoQ on May 23 2018, 5:58 PM.

Details

Summary

As noticed in http://lists.llvm.org/pipermail/cfe-dev/2018-May/058055.html we need a path-sensitive program state trait that for, essentially, every constructed object maintains the region of that object until the statement that consumes the object is encountered.

We already have such trait for new-expressions and bind/materialize temporary expressions, which are three separate traits. Because we plan to add more, it doesn't make sense to maintain that many traits that do the same thing in different circumstances, so i guess it's better to merge them into a single multi-purpose trait. "Multi-purpose" is definitely not the top buzzword in programming, but here i believe it's worth it because the underlying reasoning for needing these traits and needing them to work in a particular manner is the same. We need them because our constructor expressions are turned inside out, and we need a better connection between "inside" and "out" in both directions. One of these directions is handled by the ConstructionContext; the other is path-sensitive.

I've switched to using SVals as values of the trait because new-expressions need that and it seems to be comfortable in most situations. When the value is always a region, assertions are inserted.

No functional change intended here; this is a refactoring pass.

Diff Detail

Repository
rL LLVM

Event Timeline

NoQ created this revision.May 23 2018, 5:58 PM
NoQ edited the summary of this revision. (Show Details)May 23 2018, 6:01 PM
george.karpenkov requested changes to this revision.May 23 2018, 6:17 PM

Definitely looks much cleaner, some nits inline. Can we protect against API misuse?

include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h
769 ↗(On Diff #148324)

Should we somehow assert that those functions are called in the correct order? What will happen if e.g. finishObjectConstruction is called twice with the same statement?

lib/StaticAnalyzer/Core/ExprEngine.cpp
101 ↗(On Diff #148324)

The comment seems incorrect, the map is not only answering the "whether" question, it also maps those pairs into --- (their regions where these objects are constructed into?)

377 ↗(On Diff #148324)

nitpick: most C++ containers eliminate the need for two lookups by allowing the get method to return a reference. I'm not sure whether this can be done here though.

This revision now requires changes to proceed.May 23 2018, 6:17 PM
NoQ updated this revision to Diff 148692.May 25 2018, 5:03 PM
NoQ marked 3 inline comments as done.

Fix review comments.

lib/StaticAnalyzer/Core/ExprEngine.cpp
377 ↗(On Diff #148324)

It's likely to be harder than usual because one doesn't simply obtain a non-const reference to an object from an immutable map.

That's said, it's quite unimportant what do we do if the object is already there.

george.karpenkov accepted this revision.May 28 2018, 5:01 PM
This revision is now accepted and ready to land.May 28 2018, 5:01 PM
This revision was automatically updated to reflect the committed changes.