- SourceRange highlighting is only given for the relevant side of the operator (assignments give both)
- Added PostVisitBinaryOperator hook to retrieve the ExplodedNode for an operator
- Added a BugReporterVisitor to display the last store to every VarDecl in a Stmt
- Changed bug reporting to use the new BugReporterVisitor
llvm-svn: 112839
cursors. Sadly, this visitation is a hack, because we don't have
proper source-location information for nested-name-specifiers in the
AST. It does improve on the status quo, however.
llvm-svn: 112837
complains when the element type of a C++ "delete" expression is
different from what we would expect from the pointer type. When
deleting a bool*, we end up with an i1 on one side (where we compute
the LLVM type from the Clang bool type) and i8 on the other (where we
grab the LLVM type from the LLVM pointer type). I've weakened the
assertion appropriately, and the Boost Parallel Graph Library now
passes its regression tests.
llvm-svn: 112821
constructing an LLVM PointerType directly from the "bool"'s LLVM type
(i1), which resulted in unfortunate pointer type i1*. The fix is to
build the LLVM PointerType from the corresponding Clang PointerType,
so that we get i8* in the case of a bool.
John, please review. I also left a FIXME there because we seem to be
dropping "volatile", which would be rather unfortunate.
llvm-svn: 112819
implement ARM array cookies. Also fix a few unfortunate bugs:
- throwing dtors in deletes prevented the allocation from being deleted
- adding the cookie to the new[] size was not being considered for
overflow (and, more seriously, was screwing up the earlier checks)
- deleting an array via a pointer to array of class type was not
causing any destructors to be run and was passing the unadjusted
pointer to the deallocator
- lots of address-space problems, in case anyone wants to support
free store in a variant address space :)
llvm-svn: 112814
I'm sure it is harmless. Original commit message:
If PrototypeValue is erased in the middle of using the SSAUpdator
then the SSAUpdator may access freed memory. Instead, simply pass
in the type and name explicitly, which is all that was used anyway.
llvm-svn: 112810
function statics, file globals and static variables) that a frame contains.
The StackFrame objects can give out ValueObjects instances for
each variable which allows us to track when a variable changes and doesn't
depend on variable names when getting value objects.
StackFrame::GetVariableList now takes a boolean to indicate if we want to
get the frame compile unit globals and static variables.
The value objects in the stack frames can now correctly track when they have
been modified. There are a few more tweaks needed to complete this work. The
biggest issue is when stepping creates partial stacks (just frame zero usually)
and causes previous stack frames not to match up with the current stack frames
because the previous frames only has frame zero. We don't really want to
require that all previous frames be complete since stepping often must check
stack frames to complete their jobs. I will fix this issue tomorrow.
llvm-svn: 112800
Jim Grosbach