Summary: +updated ClangFormat.rst

Reviewers: djasper, klimek

Reviewed By: klimek

CC: cfe-commits

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

llvm-svn: 181617

llvm-svn: 181616

In most cases it is, by just looking at the name. Also, this check prevents the heuristic from working in strange user settings.
radar://13839692

llvm-svn: 181615

llvm-svn: 181611

Consider this example:

  char *p = malloc(sizeof(char));
  systemFunction(&p);
  free(p);

In this case, when we call systemFunction, we know (because it's a system
function) that it won't free 'p'. However, we /don't/ know whether or not
it will /change/ 'p', so the analyzer is forced to invalidate 'p', wiping
out any bindings it contains. But now the malloc'd region looks like a
leak, since there are no more bindings pointing to it, and we'll get a
spurious leak warning.

The fix for this is to notice when something is becoming inaccessible due
to invalidation (i.e. an imperfect model, as opposed to being explicitly
overwritten) and stop tracking it at that point. Currently, the best way
to determine this for a call is the "indirect escape" pointer-escape kind.

In practice, all the patch does is take the "system functions don't free
memory" special case and limit it to direct parameters, i.e. just the
arguments to a call and not other regions accessible to them. This is a
conservative change that should only cause us to escape regions more
eagerly, which means fewer leak warnings.

This isn't perfect for several reasons, the main one being that this
example is treated the same as the one above:

  char **p = malloc(sizeof(char *));
  systemFunction(p + 1);
  // leak

Currently, "addresses accessible by offsets of the starting region" and
"addresses accessible through bindings of the starting region" are both
considered "indirect" regions, hence this uniform treatment.

Another issue is our longstanding problem of not distinguishing const and
non-const bindings; if in the first example systemFunction's parameter were
a char * const *, we should know that the function will not overwrite 'p',
and thus we can safely report the leak.

<rdar://problem/13758386>

llvm-svn: 181607

Differential-revision: llvm-reviews.chandlerc.com/D778
llvm-svn: 181598

Otherwise (when indenting from the wrapped -> or .), this looks
like a confusing indent.

Before:
aaaaaaa        //
    .aaaaaaa( //
        aaaaaaa);
After:
aaaaaaa        //
    .aaaaaaa( //
         aaaaaaa);

llvm-svn: 181595

Patch by Robert Wilhelm.

llvm-svn: 181594

llvm-svn: 181593

llvm-svn: 181592

llvm-svn: 181591

Thereby, the macro is consistently formatted (including the trailing
escaped newlines) even if clang-format is invoked only on single lines
of the macro.

llvm-svn: 181590

Summary:
Adds actual config file reading to the clang-format utility.
Configuration file name is .clang-format. It is looked up for each input file
in its parent directories starting from immediate one. First found .clang-format
file is used. When using standard input, .clang-format is searched starting from
the current directory.
Added -dump-config option to easily create configuration files.

Reviewers: djasper, klimek

Reviewed By: klimek

CC: cfe-commits, jordan_rose, kimgr

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

llvm-svn: 181589

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

llvm-svn: 181588

MSVC provides __wchar_t. This is the same as the built-in wchar_t type
from C++, but it is also available with -fno-wchar and in C.

The commit changes ASTContext to have two different types for this:

  - WCharTy is the built-in type used for wchar_t in C++ and __wchar_t.

  - WideCharTy is the type of a wide character literal. In C++ this is
    the same as WCharTy, and in C  it is an integer type compatible with
    the type in <stddef.h>.

This fixes PR15815.

llvm-svn: 181587

Before, the actual operator of an overloaded operator declaration was
handled as a binary operator an thus, clang-format could not find valid
formattings for many examples, e.g.:

template <typename AAAAAAA, typename BBBBBBB>
AAAAAAA operator/(const AAAAAAA &a, BBBBBBB &b);

llvm-svn: 181585

substitute 'void' into the return type rather than replacing it with 'void', so
that we maintain the 'auto' type sugar.

llvm-svn: 181584

llvm-svn: 181583

[libclang] When parsing with CXTranslationUnit_ForSerialization, make sure to install the ASTWriter that we create as an ASTMutationListener.

Fixes rdar://13833268

llvm-svn: 181575

llvm-svn: 181574

But ShuffleVectorExpr should be tail-allocating the storage for expressions.

llvm-svn: 181572

llvm-svn: 181571

Now tests should pass.  The previous error was caused by a misplaced backing
array for MutableArrayRef that I introduced.

llvm-svn: 181570

llvm-svn: 181568

llvm-svn: 181565

llvm-svn: 181563

llvm-svn: 181562

for C++ constructors.

If the DIType for a class was generated by
CGDebugInfo::createContextChain(), the cache contains only a
limited DIType wihtout any declarations. Since EmitFunctionStart()
needs to find the canonical declaration for each method, we
construct the complete type before emitting any method.

rdar://problem/13116508

llvm-svn: 181561

llvm-svn: 181558

This fixes several (7 out of 16) cases of PR14492 in the GDB 7.5 test
suite. It seems GDB was bailing out whenever it had even the slightest
problem with the template argument list (& I assume it didn't like
seeing template value parameters that were just simple names - perhaps
assuming that lone names must be types, not values)

llvm-svn: 181556

llvm-svn: 181554

llvm-svn: 181553

Both these tests were ultimately fixed by the check for
"isIncompleteType" & neither test case was really reduced to a minimal
form. On doing so it becomes apparent that the problem wasn't specific
to templates at all, so I've moved the test case to a more appropriate
test file and added FileCheck verification to it (to show the forward
declaration of the array element type as well as the array alignment and
size being 0 since it cannot be computed). That's about as far down this
rabbithole as I'm willing to go today, so the rest of the un-FileChecked
tests in test/CodeGenCXX/debug-info.cpp will have to go another day
without actually testing anything other than the fact that they don't
crash.

& improve the actually interesting test case in
test/CodeGenCXX/debug-info-templates.cpp which was my original goal (in
preparation for expanding it/fixing some related bugs in non-type
template parameters)

llvm-svn: 181552

llvm-svn: 181550

llvm-svn: 181546

Patch by Robert Wilhelm.

llvm-svn: 181544

Summary:
This only supports converting along non-virtual inheritance paths by
changing the field offset or the non-virtual base adjustment.

This implements three kinds of conversions:
- codegen for Value conversions
- Constant emission for APValue
- Constant folding for CastExprs

In almost all constant initialization settings
EmitMemberPointer(APValue) is called, except when the expression
contains a reinterpret cast.

reinterpret casts end up being a big corner case because the null value
changes between different kinds of member pointers.

Reviewers: rsmith

CC: cfe-commits

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

llvm-svn: 181543

This was added, untested (though the relevant crash was tested), in
r128725/PR9600. Removing it doesn't cause failures & nothing I can
imagine could cause this check to ever return 'true' (we should never be
dealing with dependent types here). The subsequent change to check
"isIncompleteType" (r128855/PR9608) makes a lot more sense.

llvm-svn: 181542

The return type of the destructor may vary between platforms, so stop
inadvertently testing it.

llvm-svn: 181541

EmitCapturedStmt creates a captured struct containing all of the captured
variables, and then emits a call to the outlined function.  This is similar in
principle to EmitBlockLiteral.

GenerateCapturedFunction actually produces the outlined function.  It is based
on GenerateBlockFunction, but is much simpler.  The function type is determined
by the parameters that are in the CapturedDecl.

Some changes have been added to this patch that were reviewed as part of the
serialization patch and moving the parameters to the captured decl.

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

llvm-svn: 181536