Half the internet has wildly incorrect ideas about what LLVM is (in
particular, many get the impression that LLVM is some magical
cross-platform runtime), so saying "LLVM" near "cross-compilation" in a
user-facing doc might provoke confusion.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190338 91177308-0d34-0410-b5e6-96231b3b80d8

Last I heard LSan is getting close to prime-time, but for now keep
LeakSanitizer.rst hidden (especially since it contains so little
content).

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190337 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190336 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190333 91177308-0d34-0410-b5e6-96231b3b80d8

Apparently folks run into this (PR17097). The flag is not supported by
MSVC either, but we should parse it so we don't get confused when it occurs.

This changes the clang-cl output for "clang-cl /c /o foo.obj" from:

  clang-cl.exe: error: no such file or directory: '/o'
  clang-cl.exe: error: no such file or directory: 'foo.obj'

to:

  clang-cl.exe: warning: argument unused during compilation: '/o bajs.obj'

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190323 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190316 91177308-0d34-0410-b5e6-96231b3b80d8

it is an implicit instantiation of a class template specialization), pick the
first-loaded definition to be the canonical definition, and merge all other
definitions into it.

This is still rather incomplete -- we need to extend every form of declaration
that can appear within a CXXRecordDecl to be redeclarable if it came from an
AST file (this includes fields, enumerators, ...).


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190315 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190314 91177308-0d34-0410-b5e6-96231b3b80d8

PR17105.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190312 91177308-0d34-0410-b5e6-96231b3b80d8

Noticed by Roman Divacky.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190311 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190305 91177308-0d34-0410-b5e6-96231b3b80d8

Removing the endian attribute and updating associated test cases.  This functionality was never completely implemented, and this is an improvement over silently eating the attribute.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190303 91177308-0d34-0410-b5e6-96231b3b80d8

"long long" which is currently technically only "reserved for future" use in OpenCL, but
since clang in OpenCL mode supports it we may as well test the modifications to
the settings made for that type.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190297 91177308-0d34-0410-b5e6-96231b3b80d8

languages, as well as specifying errno is not set by the math functions. Make the
clang front-end set those appropriately when the OpenCL language option is set.

Patch by Erik Schnetter!



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190296 91177308-0d34-0410-b5e6-96231b3b80d8

-- For TargetInfo::getRealTypeByWidth also added support for IEEEQuad float type.



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190294 91177308-0d34-0410-b5e6-96231b3b80d8

name lookup from lazily deserializing the other declarations with the same
name, by tracking a bit to indicate whether a name in a DeclContext might have
additional external results. This also allows lazier reconciling of the lookup
table if a module import adds decls to a pre-existing DC.

However, this exposes a pre-existing bug, which causes a regression in
test/Modules/decldef.mm: if we have a reference to a declaration, and a
later-imported module adds a redeclaration, nothing causes us to load that
redeclaration when we use or emit the reference (which can manifest as a
reference to an undefined inline function, a use of an incomplete type, and so
on). decldef.mm has been extended with an additional testcase which fails with
or without this change.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190293 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190291 91177308-0d34-0410-b5e6-96231b3b80d8

SADDL, UADDL, SADDW, UADDW, SSUBL, USUBL, SSUBW, USUBW, ADDHN, RADDHN, SABAL, UABAL, SUBHN, RSUBHN, SABDL, UABDL, SMLAL, UMLAL, SMLSL, UMLSL, SQDMLAL, SQDMLSL, SMULL, UMULL, SQDMULL, PMULL



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190289 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190281 91177308-0d34-0410-b5e6-96231b3b80d8

Let clang-format consistently keep up to one empty line (configured via
FormatStyle::MaxEmptyLinesToKeep) in nested blocks, e.g. lambdas. Also,
actually format single statements in nested blocks.

Before:
  DEBUG({ int     i; });
  DEBUG({
    int i;
    // an empty line here would just be removed.
    int j;
  });

After:
  DEBUG({ int i; });
  DEBUG({
    int i;

    int j;
  });

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190278 91177308-0d34-0410-b5e6-96231b3b80d8

Improve readability. No functionality change.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190268 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190257 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190249 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190248 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190247 91177308-0d34-0410-b5e6-96231b3b80d8

remove the description about clang & llvm in the freebsd section (the reader probably know what are llvm and clang

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190246 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190245 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190244 91177308-0d34-0410-b5e6-96231b3b80d8

Update the link to the current code coverage reports (the previous one has not been updated since february 2010) + remove the spec references, not updated since May 2010

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190243 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190241 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
__uuidof on templated types should exmaine if any of its template
parameters have a uuid declspec.  If exactly one does, then take it.
Otherwise, issue an appropriate error.

Reviewers: rsmith, thakis, rnk

CC: cfe-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190240 91177308-0d34-0410-b5e6-96231b3b80d8

For clarity, renamed (get/set)ParenRange as (get/set)ParenOrBraceRange
in CXXConstructExpr nodes.
Added testcase.



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190239 91177308-0d34-0410-b5e6-96231b3b80d8

preserve getter's attribute. Also, do not attach
an inferred NS_RETURNS_INNER_POINTER to the inferred
property (it is illegal).


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190223 91177308-0d34-0410-b5e6-96231b3b80d8

The groups of libm LIBBUILTIN definitions are reordered to match the order of
the corresponding __builtin_* definitions (which occur earlier in the
Builtins.def file).

No functionality change intended.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190222 91177308-0d34-0410-b5e6-96231b3b80d8

The libm LIBBUILTIN definitions are reordered to the canonical (and
alphabetical) double (''), float ('f'), long double ('l') ordering.

No functionality change intended.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190218 91177308-0d34-0410-b5e6-96231b3b80d8

The libm math functions should be marked with the "n" (nothrow) flag so that
the corresponding IR function declarations are tagged with the nounwind
attribute (this has been true in C mode, but not in C++ mode).

The test case has been updated to run in C++ mode in addition to in C mode.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190217 91177308-0d34-0410-b5e6-96231b3b80d8

sequence. All that matters here is whether we're doing the
std::initializer_list special case thing.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190213 91177308-0d34-0410-b5e6-96231b3b80d8

Before:
  Constructor()
      : aaaaaaaaaaaaaaaaaaaa(a), bbbbbbbbbbbbbbbbbbbbbbbb(b) {
                                 }
After:
  Constructor()
      : aaaaaaaaaaaaaaaaaaaa(a), bbbbbbbbbbbbbbbbbbbbbbbb(b) {
  }

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190209 91177308-0d34-0410-b5e6-96231b3b80d8

The explicit type specified for an enum can actually have a nested name
specifier.

This fixes llvm.org/PR17125.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190208 91177308-0d34-0410-b5e6-96231b3b80d8

Before:
  double &operator[](int i) { return 0; } int i;

After:
  double &operator[](int i) { return 0; }
  int i;

This fixes llvm.org/PR17134.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190207 91177308-0d34-0410-b5e6-96231b3b80d8