[analyzer] Remove rdar links from static analyzer and libAnalysis sources. NFC.

I actually visited each link and added relevant context directly to the code.

This is related to the effort to elimin

[analyzer] Remove rdar links from static analyzer and libAnalysis sources. NFC.

I actually visited each link and added relevant context directly to the code.

This is related to the effort to eliminate internal bug tracker links
(d618f1c, e0ac46e).

Test files still have a lot of rdar links and ids in them.
I haven't touched them yet.

show more ...

Revert "Remove rdar links; NFC"

This reverts commit d618f1c3b12effd0c2bdb7d02108d3551f389d3d.
This commit wasn't reviewed ahead of time and significant concerns were
raised immediately after it land

Revert "Remove rdar links; NFC"

This reverts commit d618f1c3b12effd0c2bdb7d02108d3551f389d3d.
This commit wasn't reviewed ahead of time and significant concerns were
raised immediately after it landed. According to our developer policy
this warrants immediate revert of the commit.

https://llvm.org/docs/DeveloperPolicy.html#patch-reversion-policy

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

show more ...

Remove rdar links; NFC

This removes links to rdar, which is an internal bug tracker that the
community doesn't have visibility into.

See further discussion at:
https://discourse.llvm.org/t/code-rev

Remove rdar links; NFC

This removes links to rdar, which is an internal bug tracker that the
community doesn't have visibility into.

See further discussion at:
https://discourse.llvm.org/t/code-review-reminder-about-links-in-code-commit-messages/71847

show more ...

[analyzer] Remove the loop from the exploded graph caused by missing information in program points

This patch adds CFGElementRef to ProgramPoints
and helps the analyzer to differentiate between
two

[analyzer] Remove the loop from the exploded graph caused by missing information in program points

This patch adds CFGElementRef to ProgramPoints
and helps the analyzer to differentiate between
two otherwise identically looking ProgramPoints.

Fixes #60412

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

show more ...

[clang] Qualify auto in range-based for loops (NFC)

[analyzer][NFC] Don't bind values to ObjCForCollectionStmt, replace it with a GDM trait

Based on the discussion in D82598#2171312. Thanks @NoQ!

D82598 is titled "Get rid of statement liveness, beca

[analyzer][NFC] Don't bind values to ObjCForCollectionStmt, replace it with a GDM trait

Based on the discussion in D82598#2171312. Thanks @NoQ!

D82598 is titled "Get rid of statement liveness, because such a thing doesn't
exist", and indeed, expressions express a value, non-expression statements
don't.

if (a && get() || []{ return true; }())
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ has a value
~ has a value
~~~~~~~~~~ has a value
~~~~~~~~~~~~~~~~~~~~ has a value
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ doesn't have a value

That is simple enough, so it would only make sense if we only assigned symbolic
values to expressions in the static analyzer. Yet the interface checkers can
access presents, among other strange things, the following two methods:

ProgramState::BindExpr(const Stmt *S, const LocationContext *LCtx, SVal V,
bool Invalidate=true)
ProgramState::getSVal(const Stmt *S, const LocationContext *LCtx)

So, what gives? Turns out, we make an exception for ReturnStmt (which we'll
leave for another time) and ObjCForCollectionStmt. For any other loops, in order
to know whether we should analyze another iteration, among other things, we
evaluate it's condition. Which is a problem for ObjCForCollectionStmt, because
it simply doesn't have one (CXXForRangeStmt has an implicit one!). In its
absence, we assigned the actual statement with a concrete 1 or 0 to indicate
whether there are any more iterations left. However, this is wildly incorrect,
its just simply not true that the for statement has a value of 1 or 0, we can't
calculate its liveness because that doesn't make any sense either, so this patch
turns it into a GDM trait.

Fixing this allows us to reinstate the assert removed in
https://reviews.llvm.org/rG032b78a0762bee129f33e4255ada6d374aa70c71.

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

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

[analyzer] [NFC] Remove unused parameters, as found by -Wunused-parameter

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

llvm-svn: 343353

[analyzer] Add support for constructors of arguments.

Once CFG-side support for argument construction contexts landed in r338436,
the analyzer could make use of them to evaluate argument constructor

[analyzer] Add support for constructors of arguments.

Once CFG-side support for argument construction contexts landed in r338436,
the analyzer could make use of them to evaluate argument constructors properly.

When evaluated as calls, constructors of arguments now use the variable region
of the parameter as their target. The corresponding stack frame does not yet
exist when the parameter is constructed, and this stack frame is created
eagerly.

Construction of functions whose body is unavailable and of virtual functions
is not yet supported. Part of the reason is the analyzer doesn't consistently
use canonical declarations o identify the function in these cases, and every
re-declaration or potential override comes with its own set of parameter
declarations. Also it is less important because if the function is not
inlined, there's usually no benefit in inlining the argument constructor.

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

llvm-svn: 339745

show more ...

[analyzer] Correctly model iteration through "nil" objects

Previously, iteration through nil objects which resulted from
objc-messages being set to nil were modeled incorrectly.

There are a couple

[analyzer] Correctly model iteration through "nil" objects

Previously, iteration through nil objects which resulted from
objc-messages being set to nil were modeled incorrectly.

There are a couple of notes about this patch:

In principle, ExprEngineObjC might be left untouched IFF osx.loops
checker is enabled.
I however think that we should not do something
completely incorrect depending on what checkers are left on.
We should evaluate and potentially remove altogether the isConsumedExpr
performance heuristic, as it seems very fragile.

rdar://22205149

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

llvm-svn: 326982

show more ...

[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

[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

show more ...

[analyzer] Restore behavior change introduced by r247657.

r247657 fixed warnings about unused variables when compiling without asserts
but changed behavior. This commit restores the old behavior but

[analyzer] Restore behavior change introduced by r247657.

r247657 fixed warnings about unused variables when compiling without asserts
but changed behavior. This commit restores the old behavior but still suppresses
the warnings.

llvm-svn: 247660

show more ...

ExprEngineObjC.cpp: Fix warnings. [-Wunused-variable]

llvm-svn: 247657

[analyzer] Skip Pre/Post handlers for ObjC calls when receiver is nil.

In Objective-C, method calls with nil receivers are essentially no-ops. They
do not fault (although the returned value may be g

[analyzer] Skip Pre/Post handlers for ObjC calls when receiver is nil.

In Objective-C, method calls with nil receivers are essentially no-ops. They
do not fault (although the returned value may be garbage depending on the
declared return type and architecture). Programmers are aware of this
behavior and will complain about a false alarm when the analyzer
diagnoses API violations for method calls when the receiver is known to
be nil.

Rather than require each individual checker to be aware of this behavior
and suppress a warning when the receiver is nil, this commit
changes ExprEngineObjC so that VisitObjCMessage skips calling checker
pre/post handlers when the receiver is definitely nil. Instead, it adds a
new event, ObjCMessageNil, that is only called in that case.

The CallAndMessageChecker explicitly cares about this case, so I've changed it
to add a callback for ObjCMessageNil and moved the logic in PreObjCMessage
that handles nil receivers to the new callback.

rdar://problem/18092611

Differential Revision: http://reviews.llvm.org/D12123

llvm-svn: 247653

show more ...

[Static Analyzer] Relaxing a caching out related assert.

Differential Revision: http://reviews.llvm.org/D12818

llvm-svn: 247598

[analyzer] Apply whitespace cleanups by Honggyu Kim.

llvm-svn: 246978

[C++11] Use 'nullptr'. StaticAnalyzer edition.

llvm-svn: 209642

[C++11] Replace llvm::tie with std::tie.

llvm-svn: 202639

Include llvm::Optional in clang/Basic/LLVM.h

Post-commit CR feedback from Jordan Rose regarding r175594.

llvm-svn: 175679

Replace SVal llvm::cast support to be well-defined.

See r175462 for another example/more details.

llvm-svn: 175594

[analyzer] Remove unused fields from ExprEngine.

'currStmt', 'CleanedState', and 'EntryNode' were being set, but only ever
used locally.

llvm-svn: 169529

[analyzer] Allow ObjC ivar lvalues where the base is nil.

By analogy with C structs, this seems to be legal, if probably discouraged.
It's only if the ivar is read from or written to that there's a

[analyzer] Allow ObjC ivar lvalues where the base is nil.

By analogy with C structs, this seems to be legal, if probably discouraged.
It's only if the ivar is read from or written to that there's a problem.
Running a program that gets the "address" of an instance variable does in
fact return the offset when the base "object" is nil.

This isn't a full revert because r164442 includes some diagnostic tweaks
as well; those have been kept.

This partially reverts r164442 / 08965091770c9b276c238bac2f716eaa4da2dca4.

llvm-svn: 164960

show more ...

[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue.

Like with struct fields, we want to catch cases like this early,
so that we can produce better diagnostics and path not

[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue.

Like with struct fields, we want to catch cases like this early,
so that we can produce better diagnostics and path notes:

PointObj *p = nil;
int *px = &p->_x; // should warn here
*px = 1;

llvm-svn: 164442

show more ...

Refactor logic in ExprEngine for detecting 'noreturn' methods
in NSException to a helper object in libAnalysis that can also
be used by Sema. Not sure if the predicate name 'isImplicitNoReturn'
is t

Refactor logic in ExprEngine for detecting 'noreturn' methods
in NSException to a helper object in libAnalysis that can also
be used by Sema. Not sure if the predicate name 'isImplicitNoReturn'
is the best one, but we can massage that later.

No functionality change.

llvm-svn: 163759

show more ...

[analyzer] ObjCSelfInitChecker should always clean up in postCall checks.

ObjCSelfInitChecker stashes information in the GDM to persist it across
function calls; it is stored in pre-call checks and

[analyzer] ObjCSelfInitChecker should always clean up in postCall checks.

ObjCSelfInitChecker stashes information in the GDM to persist it across
function calls; it is stored in pre-call checks and retrieved post-call.
The post-call check is supposed to clear out the stored state, but was
failing to do so in cases where the call did not have a symbolic return
value.

This was actually causing the inappropriate cache-out from r163361.
Per discussion with Anna, we should never actually cache out when
assuming the receiver of an Objective-C message is non-nil, because
we guarded that node generation by checking that the state has changed.
Therefore, the only states that could reach this exact ExplodedNode are
ones that should have merged /before/ making this assumption.

r163361 has been reverted and the test case removed, since it won't
actually test anything interesting now.

llvm-svn: 163449

show more ...