Commit Graph

119 Commits

Author SHA1 Message Date
Alexander Kornienko 2a8c18d991 Fix typos in clang
Found via codespell -q 3 -I ../clang-whitelist.txt
Where whitelist consists of:

  archtype
  cas
  classs
  checkk
  compres
  definit
  frome
  iff
  inteval
  ith
  lod
  methode
  nd
  optin
  ot
  pres
  statics
  te
  thru

Patch by luzpaz! (This is a subset of D44188 that applies cleanly with a few
files that have dubious fixes reverted.)

Differential revision: https://reviews.llvm.org/D44188

llvm-svn: 329399
2018-04-06 15:14:32 +00:00
Artem Dergachev 9d3a7d8b2b [CFG] [analyzer] Avoid modeling C++17 constructors that aren't fully supported.
Not enough work has been done so far to ensure correctness of construction
contexts in the CFG when C++17 copy elision is in effect, so for now we
should drop construction contexts in the CFG and in the analyzer when
they seem different from what we support anyway.

This includes initializations with conditional operators and return values
across multiple stack frames.

Differential Revision: https://reviews.llvm.org/D44854

llvm-svn: 328893
2018-03-30 19:21:18 +00:00
Artem Dergachev 922455fe62 [CFG] [analyzer] Add C++17-specific ctor-initializer construction contexts.
CXXCtorInitializer-based constructors are also affected by the C++17 mandatory
copy elision, like variable constructors and return value constructors.
Extend r328248 to support those.

Differential Revision: https://reviews.llvm.org/D44763

llvm-svn: 328255
2018-03-22 22:02:38 +00:00
Artem Dergachev b9d3d30e22 [analyzer] Remove an assertion that doesn't hold in C++17.
Function return values can be constructed directly in variables or passed
directly into return statements, without even an elidable copy in between.
This is how the C++17 mandatory copy elision AST behaves. The behavior we'll
have in such cases is the "old" behavior that we've had before we've
implemented destructor inlining and proper lifetime extension support.

Differential Revision: https://reviews.llvm.org/D44755

llvm-svn: 328253
2018-03-22 21:54:48 +00:00
Artem Dergachev 317291e340 [CFG] [analyzer] Add C++17-specific variable and return construction contexts.
In C++17 copy elision is mandatory for variable and return value constructors
(as long as it doesn't involve type conversion) which results in AST that does
not contain elidable constructors in their usual places. In order to provide
construction contexts in this scenario we need to cover more AST patterns.

This patch makes the CFG prepared for these scenarios by:

- Fork VariableConstructionContext and ReturnedValueConstructionContext into
  two different sub-classes (each) one of which indicates the C++17 case and
  contains a reference to an extra CXXBindTemporaryExpr.
- Allow CFGCXXRecordTypedCall element to accept VariableConstructionContext and
  ReturnedValueConstructionContext as its context.

Differential Revision: https://reviews.llvm.org/D44597

llvm-svn: 328248
2018-03-22 21:37:39 +00:00
Artem Dergachev 98a24bf76d [analyzer] NFC: Move the code for setting temp object lifetime into method.
Differential Revision: https://reviews.llvm.org/D44129

llvm-svn: 327347
2018-03-12 23:27:52 +00:00
Artem Dergachev e078967879 [analyzer] Destroy and lifetime-extend inlined function return values properly.
This patch uses the newly added CFGCXXRecordTypedCall element at the call site
of the caller to construct the return value within the callee directly into the
caller's stack frame. This way it is also capable of populating the temporary
destructor and lifetime extension maps for the temporary, which allows
temporary destructors and lifetime extension to work correctly.

This patch does not affect temporaries that were returned from conservatively
evaluated functions.

Differential Revision: https://reviews.llvm.org/D44124

llvm-svn: 327345
2018-03-12 23:22:35 +00:00
Artem Dergachev 4449e7f008 [analyzer] Fix trivial copy for empty objects.
The SVal for any empty C++ object is an UnknownVal. Because RegionStore does
not have binding extents, binding an empty object to an UnknownVal may
potentially overwrite existing bindings at the same offset.

Therefore, when performing a trivial copy of an empty object, don't try to
take the value of the object and bind it to the copy. Doing nothing is accurate
enough, and it doesn't screw any existing bindings.

Differential Revision: https://reviews.llvm.org/D43714

llvm-svn: 326247
2018-02-27 21:10:08 +00:00
Artem Dergachev 8cd7961a0a [analyzer] Disable constructor inlining when lifetime extending through a field.
Automatic destructors are missing in the CFG in situations like

  const int &x = C().x;

For now it's better to disable construction inlining, because inlining
constructors while doing nothing on destructors is very bad.

Differential Revision: https://reviews.llvm.org/D43689

llvm-svn: 326240
2018-02-27 20:14:06 +00:00
Artem Dergachev 4068481bdb [CFG] NFC: Refactor ConstructionContext into a finite set of cases.
ConstructionContext is moved into a separate translation unit and is separated
into multiple classes. The "old" "raw" ConstructionContext is renamed into
ConstructionContextLayer - which corresponds to the idea of building the context
gradually layer-by-layer, but it isn't easy to use in the clients. Once
CXXConstructExpr is reached, layers that we've gathered so far are transformed
into the actual, "new-style" "flat" ConstructionContext, which is put into the
CFGConstructor element and has no layers whatsoever (until it actually needs
them, eg. aggregate initialization). The new-style ConstructionContext is
instead presented as a variety of sub-classes that enumerate different ways of
constructing an object in C++. There are 5 of these supported for now,
which is around a half of what needs to be supported.

The layer-by-layer buildup process is still a little bit weird, but it hides
all the weirdness in one place, that sounds like a good thing.

Differential Revision: https://reviews.llvm.org/D43533

llvm-svn: 326238
2018-02-27 20:03:35 +00:00
Artem Dergachev 308e27ee9d [analyzer] Introduce correct lifetime extension behavior in simple cases.
This patch uses the reference to MaterializeTemporaryExpr stored in the
construction context since r326014 in order to model that expression correctly.

When modeling MaterializeTemporaryExpr, instead of copying the raw memory
contents from the sub-expression's rvalue to a completely new temporary region,
that we conjure up for the lack of better options, we now have the better
option to recall the region into which the object was originally constructed
and declare that region to be the value of the expression, which is semantically
correct.

This only works when the construction context is available, which is worked on
independently.

The temporary region's liveness (in the sense of removeDeadBindings) is extended
until the MaterializeTemporaryExpr is resolved, in order to keep the store
bindings around, because it wouldn't be referenced from anywhere else in the
program state.

Differential Revision: https://reviews.llvm.org/D43497

llvm-svn: 326236
2018-02-27 19:47:49 +00:00
Aaron Ballman 6f20dc8988 Silence some -Wunused-variable warnings; NFC.
llvm-svn: 325292
2018-02-15 20:56:19 +00:00
Artem Dergachev 661ab34a31 [analyzer] Compute the correct this-region for temporary destructors.
Inline them if possible - a separate flag is added to control this.
The whole thing is under the cfg-temporary-dtors flag, off by default so far.

Temporary destructors are called at the end of full-expression. If the
temporary is lifetime-extended, automatic destructors kick in instead,
which are not addressed in this patch, and normally already work well
modulo the overally broken support for lifetime extension.

The patch operates by attaching the this-region to the CXXBindTemporaryExpr in
the program state, and then recalling it during destruction that was triggered
by that CXXBindTemporaryExpr. It has become possible because
CXXBindTemporaryExpr is part of the construction context since r325210.

Differential revision: https://reviews.llvm.org/D43104

llvm-svn: 325282
2018-02-15 19:17:44 +00:00
Artem Dergachev 5bb02f3c02 [analyzer] NFC: Eliminate ParentMap lookup in mayInlineCallKind().
Don't look at the parent statement to figure out if the cxx-allocator-inlining
flag should kick in and prevent us from inlining the constructor within
a new-expression. We now have construction contexts for that purpose.

llvm-svn: 325278
2018-02-15 19:01:55 +00:00
Artem Dergachev 9af0ed4aeb [analyzer] Inline constructors for destroyable temporaries.
Since r325210, in cfg-temporary-dtors mode, we can rely on the CFG to tell us
that we're indeed constructing a temporary, so we can trivially construct a
temporary region and inline the constructor.

Much like r325202, this is only done under the off-by-default
cfg-temporary-dtors flag because the temporary destructor, even if available,
will not be inlined and won't have the correct object value (target region).
Unless this is fixed, it is quite unsafe to inline the constructor.

If the temporary is lifetime-extended, the destructor would be an automatic
destructor, which would be evaluated with a "correct" target region - modulo
the series of incorrect relocations performed during the lifetime extension.
It means that at least, values within the object are guaranteed to be properly
escaped or invalidated.

Differential Revision: https://reviews.llvm.org/D43062

llvm-svn: 325211
2018-02-15 03:26:43 +00:00
Artem Dergachev 168e29f6af [analyzer] Decide on inlining destructors via EvalCallOptions.
EvalCallOptions were introduced in r324018 for allowing various parts of
ExprEngine to notify the inlining mechanism, while preparing for evaluating a
function call, of possible difficulties with evaluating the call that they
foresee. Then mayInlineCall() would still be a single place for making the
decision.

Use that mechanism for destructors as well - pass the necessary flags from the
CFG-element-specific destructor handlers.

Part of this patch accidentally leaked into r324018, which led into a change in
tests; this change is reverted now, because even though the change looked
correct, the underlying behavior wasn't. Both of these commits were not intended
to introduce any function changes otherwise.

Differential Revision: https://reviews.llvm.org/D42991

llvm-svn: 325209
2018-02-15 02:51:58 +00:00
Artem Dergachev 94020268fe [analyzer] Allow inlining constructors into return values.
This only affects the cfg-temporary-dtors mode - in this mode we begin inlining
constructors that are constructing function return values. These constructors
have a correct construction context since r324952.

Because temporary destructors are not only never inlined, but also don't have
the correct target region yet, this change is not entirely safe. But this
will be fixed in the subsequent commits, while this stays off behind the
cfg-temporary-dtors flag.

Lifetime extension for return values is still not modeled correctly.

Differential Revision: https://reviews.llvm.org/D42875

llvm-svn: 325202
2018-02-15 02:32:32 +00:00
Artem Dergachev e231bd342e [analyzer] NFC: Remove dead checks when computing DeclStmt construction region.
In CFG, every DeclStmt has exactly one decl, which is always a variable.

It is also pointless to check that the initializer is the constructor because
that's how construction contexts work now.

llvm-svn: 325201
2018-02-15 02:30:20 +00:00
Artem Dergachev 3da7205114 [analyzer] NFC: Assert that our fix for noreturn destructors keeps working.
Massive false positives were known to be caused by continuing the analysis
after a destructor with a noreturn attribute has been executed in the program
but not modeled in the analyzer due to being missing in the CFG.

Now that work is being done on enabling the modeling of temporary constructors
and destructors in the CFG, we need to make sure that the heuristic that
suppresses these false positives keeps working when such modeling is disabled.
In particular, different code paths open up when the corresponding constructor
is being inlined during analysis.

Differential Revision: https://reviews.llvm.org/D42779

llvm-svn: 324802
2018-02-10 03:14:22 +00:00
Artem Dergachev afb158c207 [analyzer] NFC: Use CFG construction contexts instead of homemade lookahead.
The analyzer was relying on peeking the next CFG element during analysis
whenever it was trying to figure out what object is being constructed
by a given constructor. This information is now available in the current CFG
element in all cases that were previously supported by the analyzer,
so no complicated lookahead is necessary anymore.

No functional change intended - the context in the CFG should for now be
available if and only if it was previously discoverable via CFG lookahead.

Differential Revision: https://reviews.llvm.org/D42721

llvm-svn: 324800
2018-02-10 02:55:08 +00:00
Artem Dergachev 690ab040a5 [analyzer] Don't communicate evaluation failures through memregion hierarchy.
We use CXXTempObjectRegion exclusively as a bailout value for construction
targets when we are unable to find the correct construction region.
Sometimes it works correctly, but rather accidentally than intentionally.

Now that we want to increase the amount of situations where it works correctly,
the first step is to introduce a different way of communicating our failure
to find the correct construction region. EvalCallOptions are introduced
for this purpose.

For now EvalCallOptions are communicating two kinds of problems:
- We have been completely unable to find the correct construction site.
- We have found the construction site correctly, and there's more than one of
  them (i.e. array construction which we currently don't support).

Accidentally find and fix a test in which the new approach to communicating
failures produces better results.

Differential Revision: https://reviews.llvm.org/D42457

llvm-svn: 324018
2018-02-01 22:17:05 +00:00
Artem Dergachev 50e0372f82 [analyzer] Assume that the allocated value is non-null before construction.
I.e. not after. In the c++-allocator-inlining=true mode, we need to make the
assumption that the conservatively evaluated operator new() has returned a
non-null value. Previously we did this on CXXNewExpr, but now we have to do that
before calling the constructor, because some clever constructors are sometimes
assuming that their "this" is null and doing weird stuff. We would also crash
upon evaluating CXXNewExpr when the allocator was inlined and returned null and
had a throw specification; this is UB even for custom allocators, but we still
need not to crash.

Added more FIXME tests to ensure that eventually we fix calling the constructor
for null return values.

Differential Revision: https://reviews.llvm.org/D42192

llvm-svn: 323370
2018-01-24 20:32:26 +00:00
Artem Dergachev 13b2026ba4 [analyzer] operator new: Add a new checker callback, check::NewAllocator.
The callback runs after operator new() and before the construction and allows
the checker to access the casted return value of operator new() (in the
sense of r322780) which is not available in the PostCall callback for the
allocator call.

Update MallocChecker to use the new callback instead of PostStmt<CXXNewExpr>,
which gets called after the constructor.

Differential Revision: https://reviews.llvm.org/D41406
rdar://problem/12180598

llvm-svn: 322787
2018-01-17 23:46:13 +00:00
Artem Dergachev 1084de520b [analyzer] operator new: Fix memory space for the returned region.
Make sure that with c++-allocator-inlining=true we have the return value of
conservatively evaluated operator new() in the correct memory space (heap).
This is a regression/omission that worked well in c++-allocator-inlining=false.

Heap regions are superior to regular symbolic regions because they have
stricter aliasing constraints: heap regions do not alias each other or global
variables.

Differential Revision: https://reviews.llvm.org/D41266
rdar://problem/12180598

llvm-svn: 322780
2018-01-17 22:58:35 +00:00
Artem Dergachev beba530746 [analyzer] operator new: Model the cast of returned pointer into object type.
According to [basic.stc.dynamic.allocation], the return type of any C++
overloaded operator new() is "void *". However, type of the new-expression
"new T()" and the type of "this" during construction of "T" are both "T *".

Hence an implicit cast, which is not present in the AST, needs to be performed
before the construction. This patch adds such cast in the case when the
allocator was indeed inlined. For now, in the case where the allocator was *not*
inlined we still use the same symbolic value (which is a pure SymbolicRegion of
type "T *") because it is consistent with how we represent the casts and causes
less surprise in the checkers after switching to the new behavior.

The better approach would be to represent that value as a cast over a
SymbolicRegion of type "void *", however we have technical difficulties
conjuring such region without any actual expression of type "void *" present in
the AST.

Differential Revision: https://reviews.llvm.org/D41250
rdar://problem/12180598

llvm-svn: 322777
2018-01-17 22:51:19 +00:00
Artem Dergachev 5579630275 [analyzer] operator new: Use the correct region for the constructor.
The -analyzer-config c++-allocator-inlining experimental option allows the
analyzer to reason about C++ operator new() similarly to how it reasons about
regular functions. In this mode, operator new() is correctly called before the
construction of an object, with the help of a special CFG element.

However, the subsequent construction of the object was still not performed into
the region of memory returned by operator new(). The patch fixes it.

Passing the value from operator new() to the constructor and then to the
new-expression itself was tricky because operator new() has no call site of its
own in the AST. The new expression itself is not a good call site because it
has an incorrect type (operator new() returns 'void *', while the new expression
is a pointer to the allocated object type). Additionally, lifetime of the new
expression in the environment makes it unsuitable for passing the value.
For that reason, an additional program state trait is introduced to keep track
of the return value.

Finally this patch relaxes restrictions on the memory region class that are
required for inlining the constructor. This change affects the old mode as well
(c++-allocator-inlining=false) and seems safe because these restrictions were
an overkill compared to the actual problems observed.

Differential Revision: https://reviews.llvm.org/D40560
rdar://problem/12180598

llvm-svn: 322774
2018-01-17 22:34:23 +00:00
Artem Dergachev e8ba3ec453 [analyzer] Fix a crash during C++17 aggregate construction of base objects.
Since C++17, classes that have base classes can potentially be initialized as
aggregates. Trying to construct such objects through brace initialization was
causing the analyzer to crash when the base class has a non-trivial constructor,
while figuring target region for the base class constructor, because the parent
stack frame didn't contain the constructor of the subclass, because there is
no constructor for subclass, merely aggregate initialization.

This patch avoids the crash, but doesn't provide the actually correct region
for the constructor, which still remains to be fixed. Instead, construction
goes into a fake temporary region which would be immediately discarded. Similar
extremely conservative approach is used for other cases in which the logic for
finding the target region is not yet implemented, including aggregate
initialization with fields instead of base-regions (which is not C++17-specific
but also never worked, just didn't crash).

Differential revision: https://reviews.llvm.org/D40841

rdar://problem/35441058

llvm-svn: 321128
2017-12-20 00:40:38 +00:00
Artem Dergachev 6dd11048f5 [analyzer] Enforce super-region classes for various memory regions.
We now check the type of the super-region pointer for most SubRegion classes
in compile time; some checks are run-time though.

This is an API-breaking change (we now require explicit casts to specific region
sub-classes), but in practice very few checkers are affected.

Differential Revision: https://reviews.llvm.org/D26838

llvm-svn: 300189
2017-04-13 09:56:07 +00:00
Anna Zaks b570195c3a [analyzer] Add LocationContext as a parameter to checkRegionChanges
This patch adds LocationContext to checkRegionChanges and removes
wantsRegionChangeUpdate as it was unused.

A patch by Krzysztof Wiśniewski!

Differential Revision: https://reviews.llvm.org/D27090

llvm-svn: 291869
2017-01-13 00:50:57 +00:00
Devin Coughlin 5b1ee2fad9 [analyzer] Add sink after construction of temporary with no-return destructor.
The analyzer's CFG currently doesn't have nodes for calls to temporary
destructors. This causes the analyzer to explore infeasible paths in which
a no-return destructor would have stopped exploration and so results in false
positives when no-return destructors are used to implement assertions.

To mitigate these false positives, this patch stops generates a sink after
evaluating a constructor on a temporary object that has a no-return destructor.
This results in a loss of coverage because the time at which the destructor is
called may be after the time of construction (especially for lifetime-extended
temporaries).

This addresses PR15599.

rdar://problem/29131566

llvm-svn: 290140
2016-12-19 22:23:22 +00:00
Artem Dergachev 75f9d3ac7e [analyzer] Allow undefined values in performTrivialCopy.
Reading from a garbage pointer should be modeled as garbage,
and performTrivialCopy should be able to deal with any SVal input.

Patch by Ilya Palachev!

Differential Revision: https://reviews.llvm.org/D25727

llvm-svn: 285640
2016-10-31 21:11:20 +00:00
Aleksei Sidorin 689457659b [analyzer][test commit] ExprEngine.cpp: Remove training whitespace; NFC
llvm-svn: 280352
2016-09-01 11:11:46 +00:00
Devin Coughlin 412c0af2b8 [analyzer] Better detect when C++ object was constructed into existing region.
When the analyzer evaluates a CXXConstructExpr, it looks ahead in the CFG for
the current block to detect what region the object should be constructed into.
If the constructor was directly constructed into a local variable or field
region then there is no need to explicitly bind the constructed value to
the local or field when analyzing the DeclStmt or CXXCtorInitializer that
called the constructor.

Unfortunately, there were situations in which the CXXConstructExpr was
constructed into a temporary region but when evaluating the corresponding
DeclStmt or CXXCtorInitializer the analyzer assumed the object was constructed
into the local or field. This led to spurious warnings about uninitialized
values (PR25777).

To avoid these false positives, this commit factors out the logic for
determining when a CXXConstructExpr will be directly constructed into existing
storage, adds the inverse logic to detect when the corresponding later bind can
be safely skipped, and adds assertions to make sure these two checks are in
sync.

rdar://problem/21947725

llvm-svn: 255859
2015-12-17 00:28:33 +00:00
Devin Coughlin 7bdca8b24f [analyzer] Fix crash when lambda captures a variable-length array.
When a C++ lambda captures a variable-length array, it creates a capture
field to store the size of the array. The initialization expression for this
capture is null, which led the analyzer to crash when initializing the field.
To avoid this, use the size expression from the VLA type to determine the
initialization value.

rdar://problem/23748072

llvm-svn: 254962
2015-12-07 23:01:53 +00:00
Gabor Horvath 15843343b6 [Static Analyzer] Lambda support.
Differential Revision: http://reviews.llvm.org/D12652

llvm-svn: 247426
2015-09-11 16:55:01 +00:00
Ted Kremenek 3a0678e33c [analyzer] Apply whitespace cleanups by Honggyu Kim.
llvm-svn: 246978
2015-09-08 03:50:52 +00:00
Craig Topper 0dbb783c7b [C++11] Use 'nullptr'. StaticAnalyzer edition.
llvm-svn: 209642
2014-05-27 02:45:47 +00:00
Jordan Rose bcd889730d [analyzer] Don't crash when a construction is followed by an uninitialized variable.
This could happen due to unfortunate CFG coincidences.

PR19579

llvm-svn: 207486
2014-04-29 01:56:12 +00:00
Jordan Rose 8a5a094ec5 [analyzer] Look through temporary destructors when finding a region to construct.
Fixes a false positive when temporary destructors are enabled where a temporary
is destroyed after a variable is constructed but before the VarDecl itself is
processed, which occurs when the variable is in the condition of an if or while.

Patch by Alex McCarthy, with an extra test from me.

llvm-svn: 205661
2014-04-05 02:01:41 +00:00
Jordan Rose 17f4160859 [analyzer] Extract a helper for finding the target region for a C++ constructor.
No functionality change.

Patch by Alex McCarthy!

llvm-svn: 205328
2014-04-01 16:40:06 +00:00
Jordan Rose a78de33494 [analyzer] Remove incorrect workaround for unimplemented temporary destructors.
If we're trying to get the zero element region of something that's not a region,
we should be returning UnknownVal, which is what ProgramState::getLValue will
do for us.

Patch by Alex McCarthy!

llvm-svn: 205327
2014-04-01 16:39:59 +00:00
Jordan Rose 8b808d64af [analyzer] Inline C++ operator new when c++-inline-allocators is turned on.
This will let us stage in the modeling of operator new. The -analyzer-config
opton 'c++-inline-allocators' is currently off by default.

Patch by Karthik Bhat!

llvm-svn: 201122
2014-02-11 02:21:06 +00:00
Jordan Rose 1ccc43d50e [analyzer] Handle destructors for the argument to C++ 'delete'.
Now that the CFG includes nodes for the destructors in a delete-expression,
process them in the analyzer using the same common destructor interface
currently used for local, member, and base destructors. Also, check for when
the value is known to be null, in which case no destructor is actually run.

This does not yet handle destructors for deleted /arrays/, which may need
more CFG work. It also causes a slight regression in the location of
double delete warnings; the double delete is detected at the destructor
call, which is implicit, and so is reported on the first access within the
destructor instead of at the 'delete' statement. This will be fixed soon.

Patch by Karthik Bhat!

llvm-svn: 191381
2013-09-25 16:06:17 +00:00
Pavel Labath d527cf89e6 [analyzer] Add very limited support for temporary destructors
This is an improved version of r186498. It enables ExprEngine to reason about
temporary object destructors.  However, these destructor calls are never
inlined, since this feature is still broken. Still, this is sufficient to
properly handle noreturn temporary destructors.

Now, the analyzer correctly handles expressions like "a || A()", and executes the
destructor of "A" only on the paths where "a" evaluted to false.

Temporary destructor processing is still off by default and one has to
explicitly request it by setting cfg-temporary-dtors=true.

Reviewers: jordan_rose

CC: cfe-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D1259

llvm-svn: 189746
2013-09-02 09:09:15 +00:00
Pavel Labath fce1b03ee7 [analyzer] Assume new returns non-null even under -fno-exceptions
Summary:
-fno-exceptions does not implicitly attach a nothrow specifier to every operator
new. Even in this mode, non-nothrow new must not return a null pointer. Failure
to allocate memory can be signalled by other means, or just by killing the
program. This behaviour is consistent with the compiler - even with
-fno-exceptions, the generated code never tests for null (and would segfault if
the opeator actually happened to return null).

Reviewers: jordan_rose

CC: cfe-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D1528

llvm-svn: 189452
2013-08-28 08:04:08 +00:00
Jordan Rose a7e7e7a2f6 [analyzer] Remove dead optimization for MaterializeTemporaryExpr.
Previously, we tried to avoid creating new temporary object regions if
the value to be materialized itself came from a temporary object region.
However, once we became more strict about lvalues vs. rvalues (months
ago), this optimization became dead code, because the input to this
function will always be an rvalue (i.e. a symbolic value or compound
value rather than a region, at least for structs).

This would be a nice optimization to keep, but removing it makes it
simpler to reason about temporary regions.

llvm-svn: 187160
2013-07-25 22:32:35 +00:00
Jordan Rose 6444653a06 [analyzer] Remove bogus assert: in C++11, 'new' can do list-initialization.
Previously, we asserted that whenever 'new' did not include a constructor
call, the type must be a non-record type. In C++11, however, uniform
initialization syntax (braces) allow 'new' to construct records with
list-initialization: "new Point{1, 2}".

Removing this assertion should be perfectly safe; the code here matches
what VisitDeclStmt does for regions allocated on the stack.

<rdar://problem/14403437>

llvm-svn: 186028
2013-07-10 19:14:10 +00:00
Jordan Rose b8e286548c [analyzer] Handle zeroing CXXConstructExprs.
Re-apply r184511, reverted in r184561, with the trivial default constructor
fast path removed -- it turned out not to be necessary here.

Certain expressions can cause a constructor invocation to zero-initialize
its object even if the constructor itself does no initialization. The
analyzer now handles that before evaluating the call to the constructor,
using the same "default binding" mechanism that calloc() uses, rather
than simply ignoring the zero-initialization flag.

<rdar://problem/14212563>

llvm-svn: 184815
2013-06-25 01:56:08 +00:00
Jordan Rose b3b976f061 [analyzer] Don't initialize virtual base classes more than once.
In order to make sure virtual base classes are always initialized once,
the AST contains initializers for the base class in /all/ of its
descendents, not just the immediate descendents. However, at runtime,
the most-derived object is responsible for initializing all the virtual
base classes; all the other initializers will be ignored.

The analyzer now checks to see if it's being called from another base
constructor, and if so does not perform virtual base initialization.

<rdar://problem/14236851>

llvm-svn: 184814
2013-06-25 01:55:59 +00:00
Jordan Rose e83cb0922b Revert "[analyzer] Handle zeroing CXXConstructExprs."
Per review from Anna, this really should have been two commits, and besides
it's causing problems on our internal buildbot. Reverting until these have
been worked out.

This reverts r184511 / 98123284826bb4ce422775563ff1a01580ec5766.

llvm-svn: 184561
2013-06-21 16:30:32 +00:00