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

The operators | and & in types, as opposed to the bitwise operators,
should not have whitespace around them (e.g. `Foo<Bar|Baz>`).

Patch by Martin Probst. Thank you.

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

This commit adds a named argument to AvailabilityAttr, while r263652 adds an
optional string argument to __attribute__((deprecated)).

This was commited in r263687 and reverted in 263752 due to misaligned
access.

rdar://20588929


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

Patch by Sam Parker.

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

This makes it easy to add more data into Availability.


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

/FC affects if diagnostics print with full paths and if __FILE__ expands with a
full path.  clang-cl does both of these two by default.


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

Summary:
The Microsoft compiler emits

  warning C4229: anachronism used : modifiers on data are ignored

for

  struct {} __cdecl s;

but ICU's gendict can generate such (and does when building
LibreOffice), so accepting this in clang-cl too would be useful.

Reviewers: rnk

Patch by Stephan Bergmann

Differential Revision: http://reviews.llvm.org/D16628

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

This patch adds a regular expression to configure suffixes of an
included file to check whether it is the "main" include of the current
file. Previously, clang-format has allowed arbitrary suffixes on the
formatted file, which is still the case when no IncludeMainRegex is
specified.

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

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

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

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

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

Implement lambda capture of *this by copy.
For e.g.:
struct A {

  int d = 10;
  auto foo() { return [*this] (auto a) mutable { d+=a; return d; }; }

};

auto L = A{}.foo(); // A{}'s lifetime is gone.

// Below is still ok, because *this was captured by value.
assert(L(10) == 20);
assert(L(100) == 120);

If the capture was implicit, or [this] (i.e. *this was captured by reference), this code would be otherwise undefined.

Implementation Strategy:
  - amend the parser to accept *this in the lambda introducer
  - add a new king of capture LCK_StarThis
  - teach Sema::CheckCXXThisCapture to handle by copy captures of the
    enclosing object (i.e. *this)
  - when CheckCXXThisCapture does capture by copy, the corresponding 
    initializer expression for the closure's data member 
    direct-initializes it thus making a copy of '*this'.
  - in codegen, when assigning to CXXThisValue, if *this was captured by 
    copy, make sure it points to the corresponding field member, and
    not, unlike when captured by reference, what the field member points
    to.
  - mark feature as implemented in svn

Much gratitude to Richard Smith for his carefully illuminating reviews!   


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

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

Readably displays a FunctionDecl in the Visual Studio Locals Window something like:
  void g(int, double d, struct A && arr)




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

Update the clang driver to allow -fsanitize=thread when targeting x86_64 iOS and tvOS
simulators. Also restrict TSan targeting OS X to only be supported on x86_64 and not i386.

Differential Revision: http://reviews.llvm.org/D18280

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

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

Noticed by Liu Xin. Thanks!

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

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

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

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

This reapplies r261552 and r263748. Fixed testcase to reapply.

The VFS overlay mapping between virtual paths and real paths is done through
the 'external-contents' entries in YAML files, which contains hardcoded paths
to the real files.

When a module compilation crashes, headers are dumped into <name>.cache/vfs
directory and are mapped via the <name>.cache/vfs/vfs.yaml. The script
generated for reproduction uses -ivfsoverlay pointing to file to gather the
mapping between virtual paths and files inside <name>.cache/vfs. Currently, we
are only capable of reproducing such crashes in the same machine as they
happen, because of the hardcoded paths in 'external-contents'.

To be able to reproduce a crash in another machine, this patch introduces a new
option in the VFS yaml file called 'overlay-relative'. When it's equal to
'true' it means that the provided path to the YAML file through the
-ivfsoverlay option should also be used to prefix the final path for every
'external-contents'.

Example, given the invocation snippet "... -ivfsoverlay
<name>.cache/vfs/vfs.yaml" and the following entry in the yaml file:

"overlay-relative": "true",
"roots": [
...
  "type": "directory",
  "name": "/usr/include",
  "contents": [
    {
      "type": "file",
      "name": "stdio.h",
      "external-contents": "/usr/include/stdio.h"
    },
...

Here, a file manager request for virtual "/usr/include/stdio.h", that will map
into real path "/<absolute_path_to>/<name>.cache/vfs/usr/include/stdio.h.

This is a useful feature for debugging module crashes in machines other than
the one where the error happened.

Differential Revision: http://reviews.llvm.org/D17457

rdar://problem/24499339

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

Whenever possible, use C++ names for visualizing builtin types. E.g., "long double" instead of "LongDouble"


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

Displays return type and parameters for the Function Protoype object in the Locals window.


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

Some functions can't have their address taken. If we encounter an
overload set where only one of the candidates can have its address
taken, we should automatically select that candidate's type in type
deduction.

Differential Revision: http://reviews.llvm.org/D15591


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

Some functions can't have their address taken. If we encounter an
overload set where only one of the candidates can have its address
taken, we should automatically select that candidate in cast
expressions.

Differential Revision: http://reviews.llvm.org/D17701


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

This makes sure we don't generate a lot of code to spill/reload
CSRs when calling tls_init from the access functions.

This helps performance when tls_init is not inlined into the access
functions.


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

This patch implements the following aspects:

It extends sema to check that a variable is not reference in both a map clause and firstprivate or private. This is needed to ensure correct functioning at codegen level, apart from being useful for the user.
It implements firstprivate for target in codegen. The implementation applies to both host and nvptx devices.
It adds regression tests for codegen of firstprivate, host and device side when using the host as device, and nvptx side.
Please note that the regression test for nvptx codegen is missing VLAs. This is because VLAs currently require saving and restoring the stack which appears not to be a supported operation by nvptx backend.

It adds a check in sema regression tests for target map, firstprivate, and private clauses.

http://reviews.llvm.org/D18203




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

clang -cc1 -ast-print put the struct
definition in the wrong place, like this:

  struct {} typedef S;

The reason that this happens is that the printing code
first prints the struct definition, and then tells the next
declaration to leave out the type. This behavior
is correct for simple variable declarations, but fails for
typedefs (or extern, mutable, etc).

The patch address this problem by skipping the struct
declaration when we first see it, and then telling the first
subsequent declaration that it needs to print out the full
struct definition.

Differential Revision: http://reviews.llvm.org/D17285


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

The crash occurs in WeakObjectProfileTy::getBaseInfo when getBase() is
called on an ObjCPropertyRefExpr object whose receiver is an interface.
This commit fixes the crash by checking the type of the receiver and
setting IsExact to true if it is an interface.

rdar://problem/25208167

Differential Revision: http://reviews.llvm.org/D18268


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

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

Summary:
r246764 handled __fp16 arguments and returns for AAPCS, but skipped this
handling for OpenCL.  Simlar to OpenCL, RenderScript also handles __fp16
type natively.

This patch adds the -fnative-half-arguments-and-returns command line
flag to allow such languages to skip this coercion of __fp16.

Reviewers: srhines, olista01

Subscribers: cfe-commits

Differential Revision: http://reviews.llvm.org/D18138

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

This change shows members of DeclContext objects in the Visual Studio debugger. It will also cast a TagType like a class or a struct to a DeclContext, so its methods and fields are visualized. 



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

We lost copy semantics in r263730, because it only worked for a few very
specific cases. Move semantics don't have this issue. Sadly the
implementation is a bit messy but I don't know how to clean it up
without losing support for msvc 2013 :/

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

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

Summary:
Reworked test case after buildbot failure on windows.

This patch adds base support for codegen of the target directive on the NVPTX device.

Reviewers: ABataev

Differential Revision: http://reviews.llvm.org/D17877



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

Summary: LLVM_PREFIX could be undefined if CMAKE_INSTALL_PREFIX were set to empty.

Reviewers: kparzysz, bkramer, chandlerc

Subscribers: cfe-commits

Differential Revision: http://reviews.llvm.org/D17784

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

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

Tests failing on
http://bb.pgr.jp/builders/cmake-clang-x86_64-linux/builds/46102

This reverts commit a1683cd6c9e07359c09f86e98a4db6b4e1bc51fc.

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

This reapplies r261552.

The VFS overlay mapping between virtual paths and real paths is done through
the 'external-contents' entries in YAML files, which contains hardcoded paths
to the real files.

When a module compilation crashes, headers are dumped into <name>.cache/vfs
directory and are mapped via the <name>.cache/vfs/vfs.yaml. The script
generated for reproduction uses -ivfsoverlay pointing to file to gather the
mapping between virtual paths and files inside <name>.cache/vfs. Currently, we
are only capable of reproducing such crashes in the same machine as they
happen, because of the hardcoded paths in 'external-contents'.

To be able to reproduce a crash in another machine, this patch introduces a new
option in the VFS yaml file called 'overlay-relative'. When it's equal to
'true' it means that the provided path to the YAML file through the
-ivfsoverlay option should also be used to prefix the final path for every
'external-contents'.

Example, given the invocation snippet "... -ivfsoverlay
<name>.cache/vfs/vfs.yaml" and the following entry in the yaml file:

"overlay-relative": "true",
"roots": [
...
  "type": "directory",
  "name": "/usr/include",
  "contents": [
    {
      "type": "file",
      "name": "stdio.h",
      "external-contents": "/usr/include/stdio.h"
    },
...

Here, a file manager request for virtual "/usr/include/stdio.h", that will map
into real path "/<absolute_path_to>/<name>.cache/vfs/usr/include/stdio.h.

This is a useful feature for debugging module crashes in machines other than
the one where the error happened.

Differential Revision: http://reviews.llvm.org/D17457

rdar://problem/24499339

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