I thought about this some more, and using the LocationContext might be a reasonable place to put checker-specific data that represents "global" information (i.e not specific to a GRState) but also limited in scope (i.e. the data is limited to the scope of analyzing a given *call* to a function). Once we support analysis inlining, it will be possible for multiple LocationContext objects to be around at the once for the same function. Are the statistics you are interested in specific to a given LocationContext?
On Apr 11, 2011, at 10:19 AM, Ted Kremenek <[email protected]> wrote: > Hi Lei, > > LocationContext should not contain any checker-specific data. It is only > intended to model context-sensitivity (i.e., it simulates an abstract stack > frame, or "location" in an abstract call chain). > > What are you trying to do? > > Ted > > On Apr 10, 2011, at 8:26 PM, 章磊 wrote: > >> Hi Clang, >> >> This patch add a DenseMap to record the CheckedReturn count for a >> functiondecl(fielddecl, vardecl as function pointer) in LocationContext. >> >> ImmutableMap seems not alright here, is DenseMap ok? >> >> And how to make it checker-specific? >> >> This patch is preparation for statistical UncheckedRenturn checker. >> I'll appreciate it if there are any advice about this patch. >> >> -- >> Best regards! >> >> Lei Zhang >> <CRResultMap.patch>_______________________________________________ >> cfe-commits mailing list >> [email protected] >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits > > > _______________________________________________ > cfe-commits mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
