Commit Graph

34 Commits

Author SHA1 Message Date
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 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 d3c54313ab [analyzer] NFC: Run many existing C++ tests with a custom operator new().
In order to provide more test coverage for inlined operator new(), add more
run-lines to existing test cases, which would trigger our fake header
to provide a body for operator new(). Most of the code should still behave
reasonably. When behavior intentionally changes, #ifs are provided.

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

llvm-svn: 323376
2018-01-24 21:24:10 +00:00
Artem Dergachev a396df3472 [analyzer] Enable c++-allocator-inlining by default.
This allows the analyzer to analyze ("inline") custom operator new() calls and,
even more importantly, inline constructors of objects that were allocated
by any operator new() - not necessarily a custom one.

All changes in the tests in the current commit are intended improvements,
even if they didn't carry any explicit FIXME flag.

It is possible to restore the old behavior via

  -analyzer-config c++-allocator-inlining=false

(this flag is supported by scan-build as well, and it can be into a clang
--analyze invocation via -Xclang .. -Xclang ..). There is no intention to
remove the old behavior for now.

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

llvm-svn: 323373
2018-01-24 20:59:40 +00:00
Dominic Chen 184c6242fa Reland 4: [analyzer] NFC: Update test infrastructure to support multiple constraint managers
Summary: Replace calls to %clang/%clang_cc1 with %clang_analyze_cc1 when invoking static analyzer, and perform runtime substitution to select the appropriate constraint manager, per D28952.

Reviewers: xazax.hun, NoQ, zaks.anna, dcoughlin

Subscribers: mgorny, rgov, mikhail.ramalho, a.sidorin, cfe-commits

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

llvm-svn: 296895
2017-03-03 18:02:02 +00:00
Dominic Chen 09d66f7528 Revert "Reland 3: [analyzer] NFC: Update test infrastructure to support multiple constraint managers"
This reverts commit ea36f1406e1f36bf456c3f3929839b024128e468.

llvm-svn: 296841
2017-03-02 23:30:53 +00:00
Dominic Chen feaf9ff5ee Reland 3: [analyzer] NFC: Update test infrastructure to support multiple constraint managers
Summary: Replace calls to %clang/%clang_cc1 with %clang_analyze_cc1 when invoking static analyzer, and perform runtime substitution to select the appropriate constraint manager, per D28952.

Reviewers: xazax.hun, NoQ, zaks.anna, dcoughlin

Subscribers: mgorny, rgov, mikhail.ramalho, a.sidorin, cfe-commits

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

llvm-svn: 296837
2017-03-02 23:05:45 +00:00
Dominic Chen 4a90bf8c3f Revert "Reland 2: [analyzer] NFC: Update test infrastructure to support multiple constraint managers"
This reverts commit f93343c099fff646a2314cc7f4925833708298b1.

llvm-svn: 296836
2017-03-02 22:58:06 +00:00
Dominic Chen 1cb0256a3c Reland 2: [analyzer] NFC: Update test infrastructure to support multiple constraint managers
Summary: Replace calls to %clang/%clang_cc1 with %clang_analyze_cc1 when invoking static analyzer, and perform runtime substitution to select the appropriate constraint manager, per D28952.

Reviewers: xazax.hun, NoQ, zaks.anna, dcoughlin

Subscribers: mgorny, rgov, mikhail.ramalho, a.sidorin, cfe-commits

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

llvm-svn: 296835
2017-03-02 22:45:24 +00:00
Dominic Chen 00355a51d0 Revert "Reland: [analyzer] NFC: Update test infrastructure to support multiple constraint managers"
This reverts commit 1b28d0b10e1c8feccb971abb6ef7a18bee589830.

llvm-svn: 296422
2017-02-28 01:50:23 +00:00
Dominic Chen 59cd893320 Reland: [analyzer] NFC: Update test infrastructure to support multiple constraint managers
Summary: Replace calls to %clang/%clang_cc1 with %clang_analyze_cc1 when invoking static analyzer, and perform runtime substitution to select the appropriate constraint manager, per D28952.

Reviewers: xazax.hun, NoQ, zaks.anna, dcoughlin

Subscribers: mgorny, rgov, mikhail.ramalho, a.sidorin, cfe-commits

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

llvm-svn: 296414
2017-02-28 00:02:36 +00:00
Dominic Chen 8589e10c30 Revert "[analyzer] NFC: Update test infrastructure to support multiple constraint managers"
This reverts commit 8e7780b9e59ddaad1800baf533058d2c064d4787.

llvm-svn: 296317
2017-02-27 03:29:25 +00:00
Dominic Chen 02064a3076 [analyzer] NFC: Update test infrastructure to support multiple constraint managers
Summary: Replace calls to %clang/%clang_cc1 with %clang_analyze_cc1 when invoking static analyzer, and perform runtime substitution to select the appropriate constraint manager, per D28952.

Reviewers: xazax.hun, NoQ, zaks.anna, dcoughlin

Subscribers: mgorny, rgov, mikhail.ramalho, a.sidorin, cfe-commits

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

llvm-svn: 296312
2017-02-27 02:36:15 +00:00
Alp Toker d473363876 Correct hyphenations in comments and assert messages
This patch tries to avoid unrelated changes other than fixing a few
hyphen-related ambiguities in nearby lines.

llvm-svn: 196466
2013-12-05 04:47:09 +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
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
Anton Yartsev cb2ccd6b79 [analyzer] Switched to checkPreCall interface for detecting usage after free.
Now the check is also applied to arguments for Objective-C method calls and to 'this' pointer.

llvm-svn: 179230
2013-04-10 22:21:41 +00:00
Anna Zaks a1de8567fc [analyzer] Shorten the malloc checker’s leak message
As per Ted’s suggestion!

llvm-svn: 178938
2013-04-06 00:41:36 +00:00
Jordan Rose 8f6b4b043a [analyzer] Handle caching out while evaluating a C++ new expression.
Evaluating a C++ new expression now includes generating an intermediate
ExplodedNode, and this node could very well represent a previously-
reachable state in the ExplodedGraph. If so, we can short-circuit the
rest of the evaluation.

Caught by the assertion a few lines later.

<rdar://problem/13510065>

llvm-svn: 178401
2013-03-30 01:31:42 +00:00
Jordan Rose 3503cb3572 [analyzer] Use evalBind for C++ new of scalar types.
These types will not have a CXXConstructExpr to do the initialization for
them. Previously we just used a simple call to ProgramState::bindLoc, but
that doesn't trigger proper checker callbacks (like pointer escape).

Found by Anton Yartsev.

llvm-svn: 178160
2013-03-27 18:10:35 +00:00
Anton Yartsev 13df03624b [analyzer] Adds cplusplus.NewDelete checker that check for memory leaks, double free, and use-after-free problems of memory managed by new/delete.
llvm-svn: 177849
2013-03-25 01:35:45 +00:00
Jordan Rose c93183042f [analyzer] Inline constructors for any object with a trivial destructor.
This allows us to better reason about status objects, like Clang's own
llvm::Optional (when its contents are trivially destructible), which are
often intended to be passed around by value.

We still don't inline constructors for temporaries in the general case.

<rdar://problem/11986434>

llvm-svn: 162681
2012-08-27 17:50:07 +00:00
Jordan Rose 5089f3b398 [analyzer] Handle new-expressions with initializers for scalars.
<rdar://problem/11818967>

llvm-svn: 160328
2012-07-16 23:38:09 +00:00
Jordan Rose a4ee064cf3 [analyzer] Introduce CXXAllocatorCall to handle placement arg invalidation.
This is NOT full-blown support for operator new, but removes some nasty
duplicated code introduced in r158784.

llvm-svn: 159608
2012-07-02 22:21:47 +00:00
Jordan Rose 4688e60861 [analyzer] Be careful about implicitly-declared operator new/delete. (PR13090)
The implicit global allocation functions do not have valid source locations,
but we still want to treat them as being "system header" functions for the
purposes of how they affect program state.

llvm-svn: 159160
2012-06-25 20:48:28 +00:00
Jordan Rose 7d2bdd538d [analyzer] Move failing 'new' test cases back into new.cpp instead of XFAILing.
Per Anna's comment, this is a better way to handle "to-do list"-type failures.
This way we'll know if any of the features get fixed; in an XFAIL file, /all/
the cases have to be fixed before lit would tell us anything.

llvm-svn: 158791
2012-06-20 05:34:32 +00:00
Jordan Rose 44320367ac [analyzer] Invalidate placement args; return the pointer given to placement new
The default global placement new just returns the pointer it is given.
Note that other custom 'new' implementations with placement args are not
guaranteed to do this.

In addition, we need to invalidate placement args, since they may be updated by
the allocator function. (Also, right now we don't properly handle the
constructor inside a CXXNewExpr, so we need to invalidate the placement args
just so that callers know something changed!)

This invalidation is not perfect because CallOrObjCMessage doesn't support
CXXNewExpr, and all of our invalidation callbacks expect that if there's no
CallOrObjCMessage, the invalidation is happening manually (e.g. by a direct
assignment) and shouldn't affect checker-specific metadata (like malloc state);
hence the malloc test case in new-fail.cpp. But region values are now
properly invalidated, at least.

The long-term solution to this problem is to rework CallOrObjCMessage into
something more general, rather than the morass of branches it is today.

<rdar://problem/11679031>

llvm-svn: 158784
2012-06-20 01:32:01 +00:00
Sebastian Redl 6047f07e81 Revert "Revert "Make CXXNewExpr contain only a single initialier, and not hold the used constructor itself.""
This reintroduces commit r150682 with a fix for the Bullet benchmark crash.

llvm-svn: 150685
2012-02-16 12:22:20 +00:00
Sebastian Redl c3a3c60040 Revert "Make CXXNewExpr contain only a single initialier, and not hold the used constructor itself."
It leads to a compiler crash in the Bullet benchmark.

This reverts commit r12014.

llvm-svn: 150684
2012-02-16 11:35:52 +00:00
Sebastian Redl 86fab844bb Make CXXNewExpr contain only a single initialier, and not hold the used constructor itself.
Holding the constructor directly makes no sense when list-initialized arrays come into play. The constructor is now held in a CXXConstructExpr, if construction is what is done. The new design can also distinguish properly between list-initialization and direct-initialization, as well as implicit default-initialization constructors and explicit value-initialization constructors. Finally, doing it this way removes redundance from the AST because CXXNewExpr doesn't try to handle both the allocation and the initialization responsibilities.

This breaks the static analysis of new expressions. I've filed PR12014 to track this.

llvm-svn: 150682
2012-02-16 10:58:10 +00:00
Argyrios Kyrtzidis 9eb02dfa89 [analyzer] Remove '-analyzer-check-objc-mem' flag, the nominee for best misnomer award.
llvm-svn: 126676
2011-02-28 19:49:42 +00:00
Argyrios Kyrtzidis 753b3ca32f [analyzer] Migrate UndefBranchChecker to CheckerV2.
llvm-svn: 126616
2011-02-28 01:27:33 +00:00
Zhongxing Xu f29231ece0 The second check point in the old test case was invalid.
llvm-svn: 101983
2010-04-21 02:22:25 +00:00
Zhongxing Xu 52c28fe61a Add test cases.
llvm-svn: 101878
2010-04-20 05:48:57 +00:00