[OPENMP 4.0] Initial support for array sections.

Adds parsing/sema analysis/serialization/deserialization for array sections in OpenMP constructs (introduced in OpenMP 4.0).
Currently it is allowed

[OPENMP 4.0] Initial support for array sections.

Adds parsing/sema analysis/serialization/deserialization for array sections in OpenMP constructs (introduced in OpenMP 4.0).
Currently it is allowed to use array sections only in OpenMP clauses that accepts list of expressions.
Differential Revision: http://reviews.llvm.org/D10732

llvm-svn: 245937

show more ...

Remove and forbid raw_svector_ostream::flush() calls.
After r244870 flush() will only compare two null pointers and return,
doing nothing but wasting run time. The call is not required any more
as th

Remove and forbid raw_svector_ostream::flush() calls.
After r244870 flush() will only compare two null pointers and return,
doing nothing but wasting run time. The call is not required any more
as the stream and its SmallString are always in sync.

Thanks to David Blaikie for reviewing.

llvm-svn: 244928

show more ...

Clarify pointer ownership semantics by hoisting the std::unique_ptr creation to the caller instead of hiding it in emitReport. NFC.

llvm-svn: 240400

Fix another ternary Visual C++ is OK wiht but gcc not.

llvm-svn: 232624

Remove many superfluous SmallString::str() calls.

Now that SmallString is a first-class citizen, most SmallString::str()
calls are not required. This patch removes a whole bunch of them, yet
there a

Remove many superfluous SmallString::str() calls.

Now that SmallString is a first-class citizen, most SmallString::str()
calls are not required. This patch removes a whole bunch of them, yet
there are lots more.

There are two use cases where str() is really needed:
1) To use one of StringRef member functions which is not available in
SmallString.
2) To convert to std::string, as StringRef implicitly converts while
SmallString do not. We may wish to change this, but it may introduce
ambiguity.

llvm-svn: 232622

show more ...

Track IntrusiveRefCntPtr::get() changes from LLVM r212366

llvm-svn: 212369

Replace OwningPtr with std::unique_ptr.

This compiles cleanly with lldb/lld/clang-tools-extra/llvm.

llvm-svn: 203279

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

llvm-svn: 202639

Expose the name of the checker producing each diagnostic message.

Summary:
In clang-tidy we'd like to know the name of the checker producing each
diagnostic message. PathDiagnostic has BugType and C

Expose the name of the checker producing each diagnostic message.

Summary:
In clang-tidy we'd like to know the name of the checker producing each
diagnostic message. PathDiagnostic has BugType and Category fields, which are
both arbitrary human-readable strings, but we need to know the exact name of the
checker in the form that can be used in the CheckersControlList option to
enable/disable the specific checker.

This patch adds the CheckName field to the CheckerBase class, and sets it in
the CheckerManager::registerChecker() method, which gets them from the
CheckerRegistry.

Checkers that implement multiple checks have to store the names of each check
in the respective registerXXXChecker method.

Reviewers: jordan_rose, krememek

Reviewed By: jordan_rose

CC: cfe-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D2557

llvm-svn: 201186

show more ...

[analyzer] tracking stores/constraints now works for ObjC ivars or struct fields.

This required more changes than I originally expected:

- ObjCIvarRegion implements "canPrintPretty" et al
- Derefer

[analyzer] tracking stores/constraints now works for ObjC ivars or struct fields.

This required more changes than I originally expected:

- ObjCIvarRegion implements "canPrintPretty" et al
- DereferenceChecker indicates the null pointer source is an ivar
- bugreporter::trackNullOrUndefValue() uses an alternate algorithm
to compute the location region to track by scouring the ExplodedGraph.
This allows us to get the actual MemRegion for variables, ivars,
fields, etc. We only hand construct a VarRegion for C++ references.
- ExplodedGraph no longer drops nodes for expressions that are marked
'lvalue'. This is to facilitate the logic in the previous bullet.
This may lead to a slight increase in size in the ExplodedGraph,
which I have not measured, but it is likely not to be a big deal.

I have validated each of the changed plist output.

Fixes <rdar://problem/12114812>

llvm-svn: 175988

show more ...

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

See r175462 for another example/more details.

llvm-svn: 175594

[analyzer] bugreporter::getDerefExpr now takes a Stmt, not an ExplodedNode.

This allows it to be used in places where the interesting statement
doesn't match up with the current node. No functionali

[analyzer] bugreporter::getDerefExpr now takes a Stmt, not an ExplodedNode.

This allows it to be used in places where the interesting statement
doesn't match up with the current node. No functionality change.

llvm-svn: 173546

show more ...

Sort all of Clang's files under 'lib', and fix up the broken headers
uncovered.

This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/util

Sort all of Clang's files under 'lib', and fix up the broken headers
uncovered.

This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.

I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.

llvm-svn: 169237

show more ...

Include pruning and general cleanup.

llvm-svn: 169095

[analyzer] Rename 'EmitReport' to 'emitReport'.

No functionality change.

llvm-svn: 167275

[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 ...

[analyzer] Enhance the member expr tracking to account for references.

As per Jordan's suggestion. (Came out of code review for r163261.)

llvm-svn: 163269

[analyzer] Remove unneeded code.

This region is set as interesting as part of trackNullOrUndefValue call,
no need to mark it as interesting twice.

llvm-svn: 163260

[analyzer] Improved diagnostic pruning for calls initializing values.

This heuristic addresses the case when a pointer (or ref) is passed
to a function, which initializes the variable (or sets it to

[analyzer] Improved diagnostic pruning for calls initializing values.

This heuristic addresses the case when a pointer (or ref) is passed
to a function, which initializes the variable (or sets it to something
other than '0'). On the branch where the inlined function does not
set the value, we report use of undefined value (or NULL pointer
dereference). The access happens in the caller and the path
through the callee would get pruned away with regular path pruning. To
solve this issue, we previously disabled diagnostic pruning completely
on undefined and null pointer dereference checks, which entailed very
verbose diagnostics in most cases. Furthermore, not all of the
undef value checks had the diagnostic pruning disabled.

This patch implements the following heuristic: if we pass a pointer (or
ref) to the region (on which the error is reported) into a function and
it's value is either undef or 'NULL' (and is a pointer), do not prune
the function.

llvm-svn: 162863

show more ...

[analyzer] Rename addTrackNullOrUndefValueVisitor to trackNullOrUndefValue.

This helper function (in the clang::ento::bugreporter namespace) may add more
than one visitor, but conceptually it's trac

[analyzer] Rename addTrackNullOrUndefValueVisitor to trackNullOrUndefValue.

This helper function (in the clang::ento::bugreporter namespace) may add more
than one visitor, but conceptually it's tracking a single use of a null or
undefined value and should do so as best it can.

Also, the BugReport parameter has been made a reference to underscore that
it is non-optional.

llvm-svn: 162720

show more ...

[analyzer] Don't assume values bound to references are automatically non-null.

While there is no such thing as a "null reference" in the C++ standard,
many implementations of references (including C

[analyzer] Don't assume values bound to references are automatically non-null.

While there is no such thing as a "null reference" in the C++ standard,
many implementations of references (including Clang's) do not actually
check that the location bound to them is non-null. Thus unlike a regular
null dereference, this will not cause a problem at runtime until the
reference is actually used. In order to catch these cases, we need to not
prune out paths on which the input pointer is null.

llvm-svn: 161288

show more ...

[analyzer] When a symbol is null, we should track its constraints.

Because of this, we would previously emit NO path notes when a parameter
is constrained to null (because there are no stores). Now

[analyzer] When a symbol is null, we should track its constraints.

Because of this, we would previously emit NO path notes when a parameter
is constrained to null (because there are no stores). Now we show where we
made the assumption, which is much more useful.

llvm-svn: 161280

show more ...

[analyzer] Add a simple check for initializing reference variables with null.

There's still more work to be done here; this doesn't catch reference
parameters or return values. But it's a step in th

[analyzer] Add a simple check for initializing reference variables with null.

There's still more work to be done here; this doesn't catch reference
parameters or return values. But it's a step in the right direction.

Part of <rdar://problem/11212286>.

llvm-svn: 161214

show more ...

Allow some BugReports to opt-out of PathDiagnostic callstack pruning until we have significantly
improved the pruning heuristics. The current heuristics are pretty good, but they make diagnostics
fo

Allow some BugReports to opt-out of PathDiagnostic callstack pruning until we have significantly
improved the pruning heuristics. The current heuristics are pretty good, but they make diagnostics
for uninitialized variables warnings particularly useless in some cases.

llvm-svn: 157734

show more ...

[analyzer] Implement basic path diagnostic pruning based on "interesting" symbols and regions.
Essentially, a bug centers around a story for various symbols and regions. We should only include
the p

[analyzer] Implement basic path diagnostic pruning based on "interesting" symbols and regions.
Essentially, a bug centers around a story for various symbols and regions. We should only include
the path diagnostic events that relate to those symbols and regions.

The pruning is done by associating a set of interesting symbols and regions with a BugReporter, which
can be modified at BugReport creation or by BugReporterVisitors.

This patch reduces the diagnostics emitted in several of our test cases. I've vetted these as
having desired behavior. The only regression is a missing null check diagnostic for the return
value of realloc() in test/Analysis/malloc-plist.c. This will require some investigation to fix,
and I have added a FIXME to the test case.

llvm-svn: 152361

show more ...