LHS type and the computation result type; this encodes information into
the AST which is otherwise non-obvious. Fix Sema to always come up with the
right answer for both of these types. Fix IRGen and the analyzer to
account for these changes. This fixes PR2601. The approach is inspired
by PR2601 comment 2.
Note that this changes real *= complex in CodeGen from a silent
miscompilation to an explicit error.
I'm not really sure that the analyzer changes are correct, or how to
test them... someone more familiar with the analyzer should check those
changes.
llvm-svn: 67889
- Added an internal helper class 'PathDiagnosticBuilder' which now bundles the
'ExecutionContinues' methods.
- Added preliminary diagnostics for short-circuit '&&' and '||'
llvm-svn: 67822
- Added a new class, 'PathDiagnosticLocation', that is a variant for
SourceLocation, SourceRange, or Stmt*. This will be used soon by
PathDiagnosticPieces to describe locations for targets of branches, locations
of events, etc.
- Did some prep. refactoring of PathDiagnosticPieces to prepare them for
adopting the new PathDiagnosticLocation
llvm-svn: 67767
Zhongxing and I discussed by email.
Main changes:
- Removed SymIntConstraintVal and SymIntConstraint
- Added SymExpr as a parent class to SymbolData, SymSymExpr, SymIntExpr
- Added nonloc::SymExprVal to wrap SymExpr
- SymbolRef is now just a typedef of 'const SymbolData*'
- Bunch of minor code cleanups in how some methods were invoked (no functionality change)
This changes are part of a long-term plan to have full symbolic expression
trees. This will be useful for lazily evaluating complicated expressions.
llvm-svn: 67731
representing symbolic expressions like 'x'+3 and 'x'+'y'. The design is
subjected to change later when we fix the class hierarchy of symbolic
expressions.
llvm-svn: 67678
<rdar://problem/6704930> involving SimpleConstraintManager not reasoning well
about symbolic constraint values involving arithmetic operators.
llvm-svn: 67534
- Conjure symbols at '--' and '++' unary operations
- Add utility method SVal::GetConjuredSymbolVal() and constify some arguments
along the way.
llvm-svn: 67395
SVal::GetRValueSymbolVal do the checking if we can symbolicate a type instead of
having BasicStoreManager do it (which wasn't always doing the check
consistently). Having this check in SVal::GetRValueSymbolVal keeps the check in
one centralized place.
llvm-svn: 67245
diagnostics. This builds on the patch that Sebastian committed and
then revert. Major differences are:
- We don't remove or use the current ".def" files. Instead, for now,
we just make sure that we're building the ".inc" files.
- Fixed CMake makefiles to run TableGen and build the ".inc" files
when needed. Tested with both the Xcode and Makefile generators
provided by CMake, so it should be solid.
- Fixed normal makefiles to handle out-of-source builds that involve
the ".inc" files.
I'll send a separate patch to the list with Sebastian's changes that
eliminate the use of the .def files.
llvm-svn: 67058
conditions. Currently the analyzer does not reason well about
promotions/truncations of symbolic values, so at branch conditions when we see:
if (condition)
and condition is something like a 'short' or 'char', essentially ignore the
promotion to 'int' so that we track constraints on the original symbolic value.
We only ignore the casts if the underlying type has the same or fewer bits as
the converted type.
This fixes:
<rdar://problem/6619921>
llvm-svn: 66899
ExplodedGraph::TrimGraph:
- Just do a DFS both ways instead of BFS-DFS. We're just determining what subset
of the nodes are reachable from the root and reverse-reachable from the bug
nodes. DFS is more efficient for this task.
BugReporter:
- MakeReportGraph: Do a reverse-BFS instead of a reverse-DFS to determine the
approximate shortest path through the simulation graph. We were seeing some
weird cases where too many loops were being reported for simple bugs. Possibly
we will need to replace this with actually computing the shortest path in
terms of line numbers.
llvm-svn: 66842
- PathDiagnosticControlFlowPiece now consists of a "start" and "end" location
to indicating the branch location and where the branch goes.
BugReporter:
- Updated BugReporter to construct PathDiagnosticControlFlowPiece objects with
"end" locations.
PlistDiagnostics:
- Plists now contain the bug "type" (not just bug "category")
- Plists now encode control-flow pieces differently than events; now the
"start" and "end" locations are recorded
llvm-svn: 66818
TypedViewRegion has a valid rvalue type. Also renamed instance variable 'T' to
'LvalueType' to make it unambiguous of its purpose.
This fixes some crashes I was seeing after:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20090309/013771.html
This is because 'isBoundable()' is defined in TypedRegion (the parent class) in
terms of the rvalue type (which could be null), while for TypedViewRegion it
should be defined in terms of the lvalue type.
llvm-svn: 66712
offset may be different that the base. Ultimately we need a better solution for
these issues, but this point-by-point fixes are gradually outlining the scope of
the problem.
llvm-svn: 66638
path-sensitivity, beyond checking to see if the value is "unknown" also check if
the ConstraintManager can handle the SVal. This allows us to recover some
path-sensitivity by actually discarding some information.
llvm-svn: 66627
- Group control flow and event PathDiagnosticPieces into PathDiagnosticMacroPieces.
- Afterwards, eliminate any PathDiagnosticMacroPieces from a PathDiagnostic that
contain no informative events.
HTMLDiagnostics:
- Use new information about PathDiagnosticMacroPieces to specially format
message bubbles for macro expansions containing interesting events.
llvm-svn: 66524
PathDiagnosticControlFlowPiece to distinguish (in the class hierarchy) between
events and control-flow diagnostic pieces. Clients must now use these directly
when constructing PathDiagnosticPieces.
llvm-svn: 66310
- Store bindings using a MemRegion -> SVal binding instead of VarDecl -> SVal
binding. This mirrors some of the idea of RegionStore, but is far simpler and
not nearly as functional. This leads to some code simplification and
some potential for some minor precision hacks.
Along the way...
- constify the use of MemRegion* in a few places
- add operator<<(llvm::raw_ostream, const MemRegion*)
llvm-svn: 66163
- Have 'TypedRegion::getRValueType()' return a null QualType for 'id<...>'
instead of aborting.
- Change 'TypedRegion::isBoundable()' to return true for all objects with a
non-null RValueType (this may not be the final behavior).
llvm-svn: 66093
multiple symbols conjured at the same location. All that is required of the tag
is that it is a fixed void* value that points to an memory address that remains
valid throughout the remainder of the lifetime of the SymbolManager.
llvm-svn: 66092
SVal::getAsLocSymbol(). This simplifies the code and allows the retain/release
checker to (I believe) also correctly reason about location symbols wrapped in
SymbolicRegions.
Along the way I cleaned up SymbolRef a little, disallowing implicit casts to
'unsigned'.
llvm-svn: 65972
giving them rough classifications (normal types, never-canonical
types, always-dependent types, abstract type representations) and
making it far easier to make sure that we've hit all of the cases when
decoding types.
Switched some switch() statements on the type class over to using this
mechanism, and filtering out those things we don't care about. For
example, CodeGen should never see always-dependent or non-canonical
types, while debug info generation should never see always-dependent
types. More switch() statements on the type class need to be moved
over to using this approach, so that we'll get warnings when we add a
new type then fail to account for it somewhere in the compiler.
As part of this, some types have been renamed:
TypeOfExpr -> TypeOfExprType
FunctionTypeProto -> FunctionProtoType
FunctionTypeNoProto -> FunctionNoProtoType
There shouldn't be any functionality change...
llvm-svn: 65591
know how to recover from an error, we can attach a hint to the
diagnostic that states how to modify the code, which can be one of:
- Insert some new code (a text string) at a particular source
location
- Remove the code within a given range
- Replace the code within a given range with some new code (a text
string)
Right now, we use these hints to annotate diagnostic information. For
example, if one uses the '>>' in a template argument in C++98, as in
this code:
template<int I> class B { };
B<1000 >> 2> *b1;
we'll warn that the behavior will change in C++0x. The fix is to
insert parenthese, so we use code insertion annotations to illustrate
where the parentheses go:
test.cpp:10:10: warning: use of right-shift operator ('>>') in template
argument will require parentheses in C++0x
B<1000 >> 2> *b1;
^
( )
Use of these annotations is partially implemented for HTML
diagnostics, but it's not (yet) producing valid HTML, which may be
related to PR2386, so it has been #if 0'd out.
In this future, we could consider hooking this mechanism up to the
rewriter to actually try to fix these problems during compilation (or,
after a compilation whose only errors have fixes). For now, however, I
suggest that we use these code modification hints whenever we can, so
that we get better diagnostics now and will have better coverage when
we find better ways to use this information.
This also fixes PR3410 by placing the complaint about missing tokens
just after the previous token (rather than at the location of the next
token).
llvm-svn: 65570
expressions of the form: 'short x = (y != 10);' While we handle 'int x = (y !=
10)' lazily, the cast to another integer type currently loses the symbolic
constraint. Eager evaluation of the constraint causes the paths to bifurcate and
eagerly evaluate 'y != 10' to a constant of 1 or 0. This should address
<rdar://problem/6619921> until we have a better (more lazy approach) for
handling promotions/truncations of symbolic integer values.
llvm-svn: 65480
- For autorelease pool tracking, keep information about the stack of pools
separate from their contents. Also, keep track of the number of times an
autorelease pool will send the "release" message to an object when the pool is
destroyed.
- Update CFRefCount::Update to return a new state instead of a reference count
binding. This will allow us to implement more complicated semantics with
autorelease pools.
llvm-svn: 65384
analyzer for array subscript expressions involving bases that are vectors. This
solution is probably a hack: it gets the lvalue of the vector instead of an
rvalue like all other types. This should be reviewed (big FIXME in
GRExprEngine).
llvm-svn: 65366
Should clang have a config.h or should we use the config.h of llvm or using the preprocessor is OK? I did a quick fix here, but having a guideline on how to handle non portable function would be great (or ask ted to stop breaking the windows build :)).
llvm-svn: 65233
handle method names that contain 'new', 'copy', etc., but those words might be
the substring of larger words such as 'newsgroup' and 'photocopy' that do not
indicate the allocation of objects. This should address the issues discussed in
<rdar://problem/6552389>.
llvm-svn: 65224
vanilla reverse-BFS followed by a forward-DFS instead of resulting to strange
histrionics (whose purpose I can no longer remember) in the reverse-BFS stage.
This fixes an assertion failure in BugReporter due to edge cases where no root
was being hit in the reverse-BFS phase.
llvm-svn: 65160
transitions and then generate a subsequent node that removes the dead symbol
bindings. This should drastically improve caching in the simulation graph when
retain-counted objects are being tracked.
llvm-svn: 65082
- Fix some grammar.
- Fix a bug where a "reference count incremented" diagnostic would not be shown
if the previous typestate was "Released" (only happens in GC mode).
llvm-svn: 64971
retain/releases performed via [... release] and CFRetain(). The former are
no-ops in GC. The checker already handled this, but now we emit nice diagnostics
to the user telling them that these are no-ops.
llvm-svn: 64937
Ted Kremenek