Range-style std::find{,_if} -> llvm::find{,_if}. NFC

llvm-svn: 357359

[analyzer] MIGChecker: Add support for more deallocator APIs.

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

llvm-svn: 357335

Revert "[analyzer] Introduce a simplified API for adding custom path notes."

This reverts commit r357323.

ASan leaks found by a buildbot :)

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

Revert "[analyzer] Introduce a simplified API for adding custom path notes."

This reverts commit r357323.

ASan leaks found by a buildbot :)

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

llvm-svn: 357332

show more ...

[analyzer] Introduce a simplified API for adding custom path notes.

Almost all path-sensitive checkers need to tell the user when something specific
to that checker happens along the execution path

[analyzer] Introduce a simplified API for adding custom path notes.

Almost all path-sensitive checkers need to tell the user when something specific
to that checker happens along the execution path but does not constitute a bug
on its own. For instance, a call to operator delete in C++ has consequences
that are specific to a use-after-free bug. Deleting an object is not a bug
on its own, but when the Analyzer finds an execution path on which a deleted
object is used, it'll have to explain to the user when exactly during that path
did the deallocation take place.

Historically such custom notes were added by implementing "bug report visitors".
These visitors were post-processing bug reports by visiting every ExplodedNode
along the path and emitting path notes whenever they noticed that a change that
is relevant to a bug report occurs within the program state. For example,
it emits a "memory is deallocated" note when it notices that a pointer changes
its state from "allocated" to "deleted".

The "visitor" approach is powerful and efficient but hard to use because
such preprocessing implies that the developer first models the effects
of the event (say, changes the pointer's state from "allocated" to "deleted"
as part of operator delete()'s transfer function) and then forgets what happened
and later tries to reverse-engineer itself and figure out what did it do
by looking at the report.

The proposed approach tries to avoid discarding the information that was
available when the transfer function was evaluated. Instead, it allows the
developer to capture all the necessary information into a closure that
will be automatically invoked later in order to produce the actual note.

This should reduce boilerplate and avoid very painful logic duplication.

On the technical side, the closure is a lambda that's put into a special kind of
a program point tag, and a special bug report visitor visits all nodes in the
report and invokes all note-producing closures it finds along the path.

For now it is up to the lambda to make sure that the note is actually relevant
to the report. For instance, a memory deallocation note would be irrelevant when
we're reporting a division by zero bug or if we're reporting a use-after-free
of a different, unrelated chunk of memory. The lambda can figure these thing out
by looking at the bug report object that's passed into it.

A single checker is refactored to make use of the new functionality: MIGChecker.
Its program state is trivial, making it an easy testing ground for the first
version of the API.

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

llvm-svn: 357323

show more ...

[analyzer] MIGChecker: Add support for more APIs.

Add more "consuming" functions. For now only vm_deallocate() was supported.

Add a non-zero value that isn't an error; this value is -305 ("MIG_NO_R

[analyzer] MIGChecker: Add support for more APIs.

Add more "consuming" functions. For now only vm_deallocate() was supported.

Add a non-zero value that isn't an error; this value is -305 ("MIG_NO_REPLY")
and it's fine to deallocate data when you are returning this error.

Make sure that the mig_server_routine annotation is inherited.

rdar://problem/35380337

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

llvm-svn: 354643

show more ...

[analyzer] MIGChecker: Fix an FN when the object is released in a destructor.

When a MIG server routine argument is released in an automatic destructor,
the Static Analyzer thinks that this happens

[analyzer] MIGChecker: Fix an FN when the object is released in a destructor.

When a MIG server routine argument is released in an automatic destructor,
the Static Analyzer thinks that this happens after the return statement, and so
the violation of the MIG convention doesn't happen.

Of course, it doesn't quite work that way, so this is a false negative.

Add a hack that makes the checker double-check at the end of function
that no argument was released when the routine fails with an error.

rdar://problem/35380337

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

llvm-svn: 354642

show more ...

[analyzer] MIGChecker: Improve intermediate diagnostic notes.

Add a BugReporterVisitor for highlighting the events of deallocating a
parameter. All such events are relevant to the emitted report (as

[analyzer] MIGChecker: Improve intermediate diagnostic notes.

Add a BugReporterVisitor for highlighting the events of deallocating a
parameter. All such events are relevant to the emitted report (as long as the
report is indeed emitted), so all of them will get highlighted.

Add a trackExpressionValue visitor for highlighting where does the error return
code come from.

Do not add a trackExpressionValue visitor for highlighting how the deallocated
argument(s) was(were) copied around. This still remains to be implemented.

rdar://problem/35380337

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

llvm-svn: 354641

show more ...

[analyzer] MIGChecker: Take advantage of the mig_server_routine annotation.

r354530 has added a new function/block/message attribute "mig_server_routine"
that attracts compiler's attention to functi

[analyzer] MIGChecker: Take advantage of the mig_server_routine annotation.

r354530 has added a new function/block/message attribute "mig_server_routine"
that attracts compiler's attention to functions that need to follow the MIG
server routine convention with respect to deallocating out-of-line data that
was passed to them as an argument.

Teach the checker to identify MIG routines by looking at this attribute,
rather than by making heuristic-based guesses.

rdar://problem/35380337

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

llvm-svn: 354638

show more ...

[analyzer] MIGChecker: A checker for Mach Interface Generator conventions.

This checker detects use-after-free bugs in (various forks of) the Mach kernel
that are caused by errors in MIG server rout

[analyzer] MIGChecker: A checker for Mach Interface Generator conventions.

This checker detects use-after-free bugs in (various forks of) the Mach kernel
that are caused by errors in MIG server routines - functions called remotely by
MIG clients. The MIG convention forces the server to only deallocate objects
it receives from the client when the routine is executed successfully.
Otherwise, if the server routine exits with an error, the client assumes that
it needs to deallocate the out-of-line data it passed to the server manually.
This means that deallocating such data within the MIG routine and then returning
a non-zero error code is always a dangerous use-after-free bug.

rdar://problem/35380337

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

llvm-svn: 354635

show more ...