With -style=file, clang-format now starts to search for a .clang-format
file starting at the file given with -assume-filename if it reads from
stdin. Otherwise, it would start searching from the current directory,
which is not helpful for editor integrations.

Also changed vim, emacs and sublime integrations to actually make use of
this flag.

This fixes llvm.org/PR17072.

llvm-svn: 190691

llvm-svn: 190688

historical remnant in r190684; remove it.

llvm-svn: 190687

address spaces which is both (1) a "semantic" concept and
(2) possibly a hardware level restriction. It is desirable to
be able to discard/merge the LLVM-level address spaces on arguments for which
there is no difference to the current backend while keeping
track of the semantic address spaces in a funciton prototype. To do this
enable addition of the address space into the name-mangling process. Add
some tests to document this behaviour against inadvertent changes.

Patch by Michele Scandale!

llvm-svn: 190684

Patch by Artyom Skrobov!

llvm-svn: 190681

Before (even with Style.Cpp11BracedListStyle):
  f(MyMap[{ composite, key }]);

After:
  f(MyMap[{composite, key}]);

llvm-svn: 190678

Summary:
Functions named "main", "wmain", "WinMain", "wWinMain", and "DllMain"
are never mangled regardless of linkage, even when compiling for kernel
mode.
Depends on D1655

Reviewers: timurrrr, pcc, rnk, whunt

CC: cfe-commits

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

llvm-svn: 190675

Before:
  enum {
    Bar = Foo < int,
    int > ::value
  };

After:
  enum {
    Bar = Foo<int, int>::value
  };

llvm-svn: 190674

Summary:
This is a first step to getting extern "C" working properly inside
clang.  There are a number of quirks but mangling declarations inside
such a function are a good first step.

Reviewers: timurrrr, pcc, cdavis5x

CC: cfe-commits

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

llvm-svn: 190671

llvm-svn: 190670

later in the code so that the expressions will have addition processing first.
This catches a few additional cases of uninitialized uses of class fields.

llvm-svn: 190657

llvm-svn: 190656

that duplicated the name of the entity being documented at the start of its
comment, and other minor tidyups.

llvm-svn: 190655

Patch by Jared Grubb!

llvm-svn: 190652

Patch by Jared Grubb!

llvm-svn: 190651

No tests because no in-tree checkers use this, but that shouldn't stop
out-of-tree checkers.

Found by Aemon Cannon!

llvm-svn: 190650

This restores the sqrt -> llvm.sqrt mapping, but only in fast-math mode
(specifically, when the UnsafeFPMath or NoNaNsFPMath CodeGen options are
enabled). The @llvm.sqrt* intrinsics have slightly different semantics from the
libm call, specifically, they are undefined when given a non-zero negative
number (the libm calls will always return NaN for any negative number).

This mapping was removed in r100613, and replaced with a TODO, but at that time
the fast-math flags were not yet implemented. Now that we have these, restoring
this mapping is important because it will enable autovectorization of sqrt
calls in loops (at least in fast-math mode).

llvm-svn: 190646

llvm-svn: 190641

When a comma occurs in a default argument or default initializer within a
class, disambiguate whether it is part of the initializer or whether it ends
the initializer.

The way this works (which I will be proposing for standardization) is to treat
the comma as ending the default argument or default initializer if the
following token sequence matches the syntactic constraints of a
parameter-declaration-clause or init-declarator-list (respectively).

This is both consistent with the disambiguation rules elsewhere (where entities
are treated as declarations if they can be), and should have no regressions
over our old behavior. I think it might also disambiguate all cases correctly,
but I don't have a proof of that.

There is an annoyance here: because we're performing a tentative parse in a
situation where we may not have seen declarations of all relevant entities (if
the comma is part of the initializer, lookup may find entites declared later in
the class), we need to turn off typo-correction and diagnostics during the
tentative parse, and in the rare case that we decide the comma is part of the
initializer, we need to revert all token annotations we performed while
disambiguating.

Any diagnostics that occur outside of the immediate context of the tentative
parse (for instance, if we trigger the implicit instantiation of a class
template) are *not* suppressed, mirroring the usual rules for a SFINAE context.

llvm-svn: 190639

<rdar://problem/14970968>

llvm-svn: 190635

llvm-svn: 190632

variable uninitialized every time we reach its (reachable) declaration, or
every time we call the surrounding function, promote the warning from
-Wmaybe-uninitialized to -Wsometimes-uninitialized.

This is still slightly weaker than desired: we should, in general, warn
if a use is uninitialized the first time it is evaluated.

llvm-svn: 190623

I think it makes sense that a Command knows how to execute itself.

There's no functionality change but i rewrote the code to avoid the manual
memory management of Argv.

My motivation for this is that I plan to subclass Command to build fall-back
functionality into clang-cl.

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

llvm-svn: 190621

This moves the code to Job.cpp, which seems like a more natural fit,
and replaces the "is this a JobList? is this a Command?" logic with
a virtual function call.

It also removes the code duplication between PrintJob and
PrintDiagnosticJob and simplifies the code a little.

There's no functionality change here, except that the Executable is
now always printed within quotes, whereas it would previously not be
quoted in crash reports, which I think was a bug.

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

llvm-svn: 190620

CMake does not have the ability to perform actions before calculating
dependencies, so it can't know whether it needs to rebuild clangBasic
to update for a new revision number. CLANG_ALWAYS_CHECK_VC_REV (off by
default) will cause clangBasic to always be dirty by deleting the
generated SVNVersion.inc after use; otherwise, SVNVersion.inc will
always be updated, but only included in the final binary when clangBasic
is rebuilt.

It'd be great to find a better way to do this, but hopefully this is
still an improvement over the complete lack of version information before.

llvm-svn: 190613

llvm-svn: 190601

rdar://14971432

llvm-svn: 190568

rdar://14887351

llvm-svn: 190561

Just always regenerate SVNVersion.inc. Don't worry about it not changing.

llvm-svn: 190560

It'd be another issue that the terminal and stdout(including redirects) with utf8. This test XPASSed on Win32, at least on Lit.

FYI, we don't use a triplet like "-win64" anywhere.

llvm-svn: 190559

Now that LLVM's helper script GetSVN.cmake actually works consistently,
there's no reason not to use it. This does mean that the clangBasic target
is potentially always dirty, because CMake-generated projects do not
necessarily recalculate dependencies after running each target.

This should end the issues of the AST format changing and breaking old
module files; CMake-Clang should now detect that the version changed just
like Autoconf-Clang has.

llvm-svn: 190557

unknown methods which return Cocoa objects. No need to annotate
such methods.

llvm-svn: 190555

Before:
  for (int i = 0; i* 2 < z; i *= 2) {}
After:
  for (int i = 0; i * 2 < z; i *= 2) {}

llvm-svn: 190546

Tablegen now generates a StringSwitch for attributes containing enumeration arguments to map strings to the proper enumeration value.  This makes error checking more consistent and reduces the amount of hand-written code required.

llvm-svn: 190545

such that it does not lower case the staring property
name if getter name (after "get" prefix) starts with 
two upper case letters.

llvm-svn: 190539

Summary:
This test only works on systems capable of outputting UTF-8 encoded
text on the standard output (tested on linux and OS X, should XFAIL on windows,
if I haven't messed up the XFAIL line).

Reviewers: jordan_rose

Reviewed By: jordan_rose

CC: cfe-commits

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

llvm-svn: 190537

llvm-svn: 190533

start with "get" are inferreed as a readonly properties.

llvm-svn: 190532

llvm-svn: 190531

RegionStore tries to protect against accidentally initializing the same
region twice, but it doesn't take subregions into account very well. If
the outer region being initialized is a struct with an empty base class,
the offset of the first field in the struct will be 0. When we initialize
the base class, we may invalidate the contents of the struct by providing
a default value of Unknown (or some new symbol). We then go to initialize
the member with a zeroing constructor, only to find that the region at
that offset in the struct already has a value. The best we can do here is
to invalidate that value and continue; neither the old default value nor
the new 0 is correct for the entire struct after the member constructor call.

The correct solution for this is to track region extents in the store.

<rdar://problem/14914316>

llvm-svn: 190530