When enabled, clang generates bounds checks for array and pointers dereferences. Work to follow in LLVM's backend.
OK'ed by Chad; thanks for the review.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156431 91177308-0d34-0410-b5e6-96231b3b80d8
disruptive, but it allows RegionStore to better "see" through casts that reinterpret arrays of values
as structs. Fixes <rdar://problem/11405978>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156428 91177308-0d34-0410-b5e6-96231b3b80d8
@throw expression; l2r conversion can introduce new cleanups
in certain cases, like when the expression is an ObjC property
reference of retainable type in ARC.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156425 91177308-0d34-0410-b5e6-96231b3b80d8
don't reason about.
Self is just like a local variable in init methods, so it can be
assigned anything like result of static functions, other methods ... So
to suppress false positives that result in such cases, stop tracking the
checker-specific state after self is being assigned to (unless the
value is't being assigned to is either self or conforms to our rules).
This change does not invalidate any existing regression tests.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156420 91177308-0d34-0410-b5e6-96231b3b80d8
For "%hhx", printf expects an unsigned char. This makes Clang
accept a 'char' argument for that also when using -funsigned-char.
This fixes PR12761.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156388 91177308-0d34-0410-b5e6-96231b3b80d8
* TranslationUnit reading and parsing now implemented as
TranslationUnit.from_ast() and TranslationUnit.from_source().
* Index.parse() and Index.read() implemented through above.
* Index.parse() and Index.read() now raise a TanslationUnitLoadException
instead of returning None if a TranslationUnit could not be
instantiated. This is backwards incompatible.
* Ability to save TranslationUnits via TranslationUnit.save().
* TranslationUnit now holds onto Index instance that created. This means
the Index can't be GC'd until the TranslationUnit is itself GC'd,
making memory management thoughtless.
* Don't use [] as a default argument value, as the initial value used is
reused for the duration of the program.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156372 91177308-0d34-0410-b5e6-96231b3b80d8
This could conceivably cut down on state proliferation, although we don't
use BasicConstraintManager by default anymore. No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156362 91177308-0d34-0410-b5e6-96231b3b80d8
This involves keeping track of three separate types: the symbol type, the
adjustment type, and the comparison type. For example, in "$x + 5 > 0ULL",
if the type of $x is 'signed char', the adjustment type is 'int' and the
comparison type is 'unsigned long long'. Most of the time these three types
will be the same, but we should still do the right thing when the
comparison value is out of range, and wraparound should be calculated in
the adjustment type.
This also re-disables an out-of-bounds test; we were extracting the symbol
from non-additive SymIntExprs, but then throwing away the integer.
Sorry for the large patch; both the basic and range constraint managers needed
to be updated together, since they share code in SimpleConstraintManager.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156361 91177308-0d34-0410-b5e6-96231b3b80d8
There are more parts of the analyzer that could use the convenience of APSIntType, particularly the constraint engine, but that needs a fair amount of rewriting to handle mixed-type constraints anyway.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156360 91177308-0d34-0410-b5e6-96231b3b80d8
a given entity, so that we can tell when the entity was
introduced/deprecated/obsoleted on each platform for which we have an
annotation. Addresses <rdar://problem/11365715>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156347 91177308-0d34-0410-b5e6-96231b3b80d8
match gcc behavior for two conflicting visibilities in the same decl. It also
makes handling of dllimport/dllexport more natural.
As a bonus we now warn on the dllimport in
void __attribute__((dllimport)) foo13();
void __attribute__((dllexport)) foo13();
as does gcc.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156343 91177308-0d34-0410-b5e6-96231b3b80d8
This is temporary until we settle on how to make the main RecursiveASTVisitor safe.
There are some modifications on the original version, to avoid extreme memory usage
when compiling for release.
rdar://11179167
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156329 91177308-0d34-0410-b5e6-96231b3b80d8
After discussion with several people, including Doug Gregor, we've
decided to change our approach here. If you have questions about this
header file, the commit removing it, etc., please reach out to me
off-list.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156322 91177308-0d34-0410-b5e6-96231b3b80d8
SValBuilder should return an UnknownVal() when comparison of int and ptr
fails. Previous to this commit, it went on assuming that we are dealing
with pointer arithmetic.
PR12509, radar://11390991
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156320 91177308-0d34-0410-b5e6-96231b3b80d8
To solve the inconsistency pointed out in Erik's review, refactor class
hierarchy of ProgramPoints so that PreStmtPurgeDeadSymbols and
PostStmtPurgeDeadSymbols both subclass from StmtPoint instead of
PostStmt.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156315 91177308-0d34-0410-b5e6-96231b3b80d8
remove the comparison of objectsize with -1. since it's an unsigned comparison, it will always succeed if objectsize returns -1, which is enough to have the check removed
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156311 91177308-0d34-0410-b5e6-96231b3b80d8
As per Jordy's and Ted's comment, use the default StopTracking summary
instead of adding all arguments to ScratchArs.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156310 91177308-0d34-0410-b5e6-96231b3b80d8
The chdir is not the perfect fix, as it is thread hostile. The
real fix will be to make -working-dir work correctly, which will
take time to implement. Before that, the tooling library cannot
be used concurrently.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156299 91177308-0d34-0410-b5e6-96231b3b80d8
overload candidate, and include its message in any subsequent 'candidate not
viable due to substitution failure' note we may produce.
To keep the note small (since the 'overload resolution failed' diagnostics are
often already very verbose), the text of the SFINAE diagnostic is included as
part of the text of the note, and any notes which were attached to it are
discarded.
There happened to be spare space in OverloadCandidate into which a
PartialDiagnosticAt could be squeezed, and this patch goes to lengths to avoid
unnecessary PartialDiagnostic copies, resulting in no slowdown that I could
measure. (Removal in passing of some PartialDiagnostic copies has resulted in a
slightly smaller clang binary overall.) Even on a torture test, I was unable to
measure a memory increase of above 0.2%.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156297 91177308-0d34-0410-b5e6-96231b3b80d8
so that we actually accumulate all the delayed diagnostics. Do
this so that we can restore those diagnostics to good standing
if it turns out that we were wrong to suppress, e.g. if the
tag specifier is actually an elaborated type specifier and not
a declaration.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156291 91177308-0d34-0410-b5e6-96231b3b80d8
separate pools owned by the RAII objects that keep pushing
decl state. This gives us quite a bit more flexibility.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156289 91177308-0d34-0410-b5e6-96231b3b80d8
- Two new tests (one for each property), require libclang built from r155858 or later to pass
- New test utility function (get_cursors) that gets all the nodes with a specific spelling.
Patch by Evan Pipho.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156286 91177308-0d34-0410-b5e6-96231b3b80d8
in-class initializer for one of its fields. Value-initialization of such
a type should use the in-class initializer!
The former was just a bug, the latter is a (reported) standard defect.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156274 91177308-0d34-0410-b5e6-96231b3b80d8