Summary: + improved handling of default style and predefined styles.

Reviewers: djasper, klimek

Reviewed By: klimek

CC: cfe-commits

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

llvm-svn: 182205

llvm-svn: 182204

imply -fno-math-errno if the user passed -fno-fast-math OR -ffast-math,
regardless of in which order and regardless of the tool chain default.

I've fixed this to follow the logic:

1) If the last dominating flag is -fno-math-errno, -ffast-math, or
   -Ofast, then do not use math-errno.
2) If the last dominating flag is an explicit -fmath-errno, do use
   math-errno.
3) Otherwise, use the toolchain default.

This, for example, allows the flag sequence
'-ffast-math ... -fno-fast-math' with no mention of '-fmath-errno' or
'-fno-math-errno' to preserve the toolchain default. Most notably, this
should prevent users trying to disable fast-math optimizations on Darwin
and BSD platforms from simultaneously enabling (pointless) -fmath-errno.

I've enhanced the tests (after more reorganization) to cover this and
other weird permutations of flags and targets.

llvm-svn: 182203

setting. Consolidate the collection of tests that enable -fmath-errno
and share a single CHECK line for simplicity.

llvm-svn: 182202

llvm-svn: 182189

llvm-svn: 182188

Constructs like PseudoObjectExpr, where an expression can appear more than
once in the AST, use OpaqueValueExprs to guard against inadvertent
re-processing of the shared expression during AST traversal. The most
common form of this is to share expressions between the syntactic
"as-written" form of, say, an Objective-C property access 'obj.prop', and
the underlying "semantic" form '[obj prop]'.

However, some constructs can produce OpaqueValueExprs that don't appear in
the syntactic form at all; in these cases the ParentMap wasn't ever traversing
the children of these expressions. This patch fixes that by checking to see
if an OpaqueValueExpr's child has ever been traversed before. There's also a
bit of reset logic when visiting a PseudoObjectExpr to handle the case of
updating the ParentMap, which some external clients depend on.

This still isn't exactly the right fix because we probably want the parent
of the OpaqueValueExpr itself to be its location in the syntactic form if
it's syntactic and the PseudoObjectExpr or BinaryConditionalOperator itself
if it's semantic. Whe I originally wrote the code to do this, I didn't realize
that OpaqueValueExprs themselves are shared in the AST, not just their source
expressions. This patch doesn't change the existing behavior so as not to
break anything inadvertently relying on it; we'll come back to this later.

llvm-svn: 182187

Originally implemented by Ted, extended by me.

llvm-svn: 182186

Ted and I spent a long time discussing this today and found out that neither
the existing code nor the new code was doing what either of us thought it
was, which is never good. The good news is we found a much simpler way to
fix the motivating test case (an ObjCSubscriptExpr).

This reverts r182083, but pieces of it will come back in subsequent commits.

llvm-svn: 182185

Thanks to John McCall for pointing this out.

llvm-svn: 182182

llvm-svn: 182178

properties declared in a protocol.

rdar://problem/13798000

llvm-svn: 182176

assert_exclusive_lock and assert_shared_lock.  These attributes are used to
mark functions that dynamically check (i.e. assert) that a lock is held.

llvm-svn: 182170

llvm-svn: 182167

llvm-svn: 182156

Patch by Seth Fowler.

llvm-svn: 182139

declaration is illegally protocol qualified. // rdar://13920026

llvm-svn: 182136

llvm-svn: 182134

is used for Objective-C++’s dictionary subscripting. This is done by filtering
out all placeholder types before check on lowering of the
common expression is done. // rdar://1374918.
Reviewed by John McCall.

llvm-svn: 182120

This shares the warn_attribute_unused diagnostic and reduces the
indentation level.  No functionality change.

llvm-svn: 182096

This optimizes some spurious edges resulting from PseudoObjectExprs.
This required far more changes than I anticipated.  The current
ParentMap does not record any hierarchy information between
a PseudoObjectExpr and its *semantic* expressions that may be
wrapped in OpaqueValueExprs, which are the expressions actually
laid out in the CFG.  This means the arrow pruning logic could
not map from an expression to its containing PseudoObjectExprs.

To solve this, this patch adds a variant of ParentMap that
returns the "semantic" parentage of expressions (essentially
as they are viewed by the CFG).  This alternate ParentMap is then
used by the arrow reducing logic to identify edges into pseudo
object expressions, and then eliminate them.

llvm-svn: 182083

Basically, the new rule is: The opening "{" always has to be on the
same line as the first element if the braced list is nested
(e.g. in another braced list or in a function).

The solution that clang-format produces almost always adheres to this
rule anyway and this makes clang-format significantly faster for larger
lists. Added a test cases for the only exception I could find
(which doesn't seem to be very important at first sight).

llvm-svn: 182082

As asked for by Sean, putting the video into the docs.

llvm-svn: 182081

This means adding an extra edge from the 'if' to the condition,
which aesthetically looks more pleasing.

llvm-svn: 182079

for a nested call.  This matches what we do with the first stack frame.

llvm-svn: 182078

llvm-svn: 182075

llvm-svn: 182074

instantiate the inherited constructor template and mark that as the constructor
which the instantiated specialization is inheriting. This fixes a
crash-on-valid when trying to compute the exception specification of a
specialization of the inheriting constructor.

llvm-svn: 182072

The analyzer can't see the reference count for shared_ptr, so it doesn't
know whether a given destruction is going to delete the referenced object.
This leads to spurious leak and use-after-free warnings.

For now, just ban destructors named '~shared_ptr', which catches
std::shared_ptr, std::tr1::shared_ptr, and boost::shared_ptr.

PR15987

llvm-svn: 182071

AST dumping: if a declaration has an uncomputed or uninstantiated exception specification, include that in the dump.

llvm-svn: 182070

Previously, we’ve used the last location of the analyzer issue path as the location of the
report. This might not provide the best user experience, when one analyzer a source
file and the issue appears in the header. Introduce an option to use the last location
of the path that is in the main source file as the report location.

New option can be enabled with -analyzer-config report-in-main-source-file=true.

llvm-svn: 182058

#steps not #1s, and use a more traditional step count where the 'halt' step is
not counted.

llvm-svn: 182057

This is a modified version of a patch by Manuel Klimek.

llvm-svn: 182055

llvm-svn: 182043

synthesize a property getter method that overrides
a method definition named 'retain' and the like.
Fixes // rdar://13885083

llvm-svn: 182039

llvm-svn: 182029

This ensures that we format:
void longFunctionName {
} // long comment here

And not:
void longFunctionName {}
// long comment here

As requested in post-commit-review.

llvm-svn: 182024

llvm-svn: 182015

llvm-svn: 182003

llvm-svn: 182001