emscripten-fastcomp-clang/test/Analysis, branch master

[analyzer] Handle CXXTemporaryObjectExprs in compound literals.

2013-05-06T16:48:20Z

This occurs because in C++11 the compound literal syntax can trigger a constructor call via list-initialization. That is, "Point{x, y}" and "(Point){x, y}" end up being equivalent. If this occurs, the inner CXXConstructExpr will have already handled the object construction; the CompoundLiteralExpr just needs to propagate that value forwards. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181213 91177308-0d34-0410-b5e6-96231b3b80d8

[analyzer] Check the stack frame when looking for a var's initialization.

2013-05-03T05:47:31Z

FindLastStoreBRVisitor is responsible for finding where a particular region gets its value; if the region is a VarRegion, it's possible that value was assigned at initialization, i.e. at its DeclStmt. However, if a function is called recursively, the same DeclStmt may be evaluated multiple times in multiple stack frames. FindLastStoreBRVisitor was not taking this into account and just picking the first one it saw. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180997 91177308-0d34-0410-b5e6-96231b3b80d8

[analyzer] Fix trackNullOrUndef when tracking args that have nil receivers.

2013-05-03T05:47:24Z

There were actually two bugs here: - if we decided to look for an interesting lvalue or call expression, we wouldn't go find its node if we also knew we were at a (different) call. - if we looked through one message send with a nil receiver, we thought we were still looking at an argument to the original call. Put together, this kept us from being able to track the right values, which means sub-par diagnostics and worse false-positive suppression. Noticed by inspection. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180996 91177308-0d34-0410-b5e6-96231b3b80d8

[analyzer] Don't try to evaluate MaterializeTemporaryExpr as a constant.

2013-05-02T19:51:20Z

...and don't consider '0' to be a null pointer constant if it's the initializer for a float! Apparently null pointer constant evaluation looks through both MaterializeTemporaryExpr and ImplicitCastExpr, so we have to be more careful about types in the callers. For RegionStore this just means giving up a little more; for ExprEngine this means handling the MaterializeTemporaryExpr case explicitly. Follow-up to r180894. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180944 91177308-0d34-0410-b5e6-96231b3b80d8

[analyzer] RetainCountChecker: don't track through xpc_connection_set_context.

2013-05-02T01:51:40Z

It is unfortunate that we have to mark these exceptions in multiple places. This was already in CallEvent. I suppose it does let us be more precise about saying /which/ arguments have their retain counts invalidated -- the connection's is still valid even though the context object's isn't -- but we're not tracking the retain count of XPC objects anyway. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180904 91177308-0d34-0410-b5e6-96231b3b80d8

[analyzer] Consolidate constant evaluation logic in SValBuilder.

2013-05-01T23:10:44Z

Previously, this was scattered across Environment (literal expressions), ExprEngine (default arguments), and RegionStore (global constants). The former special-cased several kinds of simple constant expressions, while the latter two deferred to the AST's constant evaluator. Now, these are all unified as SValBuilder::getConstantVal(). To keep Environment fast, the special cases for simple constant expressions have been left in, but the main benefits are that (a) unusual constants like ObjCStringLiterals now work as default arguments and global constant initializers, and (b) we're not duplicating code between ExprEngine and RegionStore. This actually caught a bug in our test suite, which is awesome: we stop tracking allocated memory if it's passed as an argument along with some kind of callback, but not if the callback is 0. We were testing this in a case where the callback parameter had a default value, but that value was 0. After this change, the analyzer now (correctly) flags that as a leak! git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180894 91177308-0d34-0410-b5e6-96231b3b80d8

[analyzer] Don't inline the [cd]tors of C++ iterators.

2013-05-01T22:39:31Z

This goes with r178516, which instructed the analyzer not to inline the constructors and destructors of C++ container classes. This goes a step further and does the same thing for iterators, so that the analyzer won't falsely decide we're trying to construct an iterator pointing to a nonexistent element. The heuristic for determining whether something is an iterator is the presence of an 'iterator_category' member. This is controlled under the same -analyzer-config option as container constructor/destructor inlining: 'c++-container-inlining'. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180890 91177308-0d34-0410-b5e6-96231b3b80d8

Re-apply "[analyzer] Model casts to bool differently from other numbers."

2013-05-01T18:19:59Z

This doesn't appear to be the cause of the slowdown. I'll have to try a manual bisect to see if there's really anything there, or if it's just the bot itself taking on additional load. Meanwhile, this change helps with correctness. This changes an assertion and adds a test case, then re-applies r180638, which was reverted in r180714. and PR15863 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180864 91177308-0d34-0410-b5e6-96231b3b80d8

Revert "[analyzer] Model casts to bool differently from other numbers."

2013-04-29T17:23:03Z

This seems to be causing quite a slowdown on our internal analyzer bot, and I'm not sure why. Needs further investigation. This reverts r180638 / 9e161ea981f22ae017b6af09d660bfc3ddf16a09. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180714 91177308-0d34-0410-b5e6-96231b3b80d8

[analyzer] An ObjC for-in loop runs 0 times if the collection is nil.

2013-04-26T21:43:01Z

In an Objective-C for-in loop "for (id element in collection) {}", the loop will run 0 times if the collection is nil. This is because the for-in loop is implemented using a protocol method that returns 0 when there are no elements to iterate, and messages to nil will result in a 0 return value. At some point we may want to actually model this message send, but for now we may as well get the nil case correct, and avoid the false positives that would come with this case. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180639 91177308-0d34-0410-b5e6-96231b3b80d8