Lines Matching full:are

4 There are several options that control which calls the analyzer will consider for
22    determined at runtime and we are not 100% sure that our type info is
28    has code that is only exercised when some of its methods are overridden.
35 analyzer's configuration table, so they are all specified as follows:
66 Currently, template functions are considered for inlining by default.
82 Currently, C++ standard library functions are considered for inlining by
85 The standard library functions and the STL in particular are used ubiquitously
99 Currently, these constructors and destructors are NOT considered for inlining
103 named 'iterator' or a member named 'begin'; these names are idiomatic in C++,
115 Many of these issues are avoided if containers always have unknown, symbolic
116 state, which is what happens when their constructors are treated as opaque.
117 In the future, we may decide specific containers are "safe" to model through
127 If the conditions are right for inlining, a CallEnter node is created and added
144 3. Dead symbols and bindings are cleaned out from the state, including any local
150 5. Custom post-call checks are processed and the final nodes are pushed back
172 provides a better summary of what actually happens in the program.  There are
179   cannot be computed.  These are prerequisites for analyzing a function body,
191 - In C++, constructors are not inlined unless the destructor call will be
193   implicit destructors, or if the destructors for the given object are not
202 - Calls resulting in "dynamic dispatch" are specially handled.  See more below.
214 "Dynamic" calls are those that are resolved at runtime, such as C++ virtual
275 all dynamic calls are inlined, whether we are certain or not that this will
277 only "near-perfect" devirtualized calls are inlined*, and other dynamic calls
278 are evaluated conservatively (as if no definition were available).
280 * Currently, no Objective-C messages are not inlined under
281   -analyzer-config ipa=inlining, even if we are reasonably confident of the type
287 in *addition* to inlining. The details of this are discussed below.
290 member functions or Objective-C method calls, even if they are non-virtual or
305 Currently, there are 2 modes:
327 class is subclassed. The disadvantages of this mode are a (considerable?)
336 are the cases when the DynamicTypeInfo of the object is considered precise
342  - If the calls are property accesses using dot syntax. This is based on the
360 There are several limitations in the current implementation:
362 * Temporaries are poorly modeled right now because we're not confident in the
370 * Arrays of objects are modeled very poorly right now.  ExprEngine currently
393 CallEvents are reference-counted objects managed by a CallEventManager. While
395 they are intended for short-lived use, and can be recreated from CFGElements or