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

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

This patch corresponds to review:
https://reviews.llvm.org/D26479

It adds the remaining vector permute/rotate builtins to altivec.h.


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

In r286630, Decl::setInvalidDecl will automatically set the invalid flag for
BindingDecl for children in invalid DecompositionDecl.  It no longer is
necessary to do a separate setInvalidDecl when finalizing a BindingDecl.


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

The context argument passed to VideoToolbox's
VTCompressionSessionEncodeFrame() function is ultimately passed to a callback
supplied when creating the compression session and so may be freed by that
callback.  To suppress false positives in this case, teach the retain count
checker to stop tracking that argument.

This isn't suppressed by the usual callback context mechanism because the call
to VTCompressionSessionEncodeFrame() doesn't include the callback itself.

rdar://problem/27685213

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

invalid.


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

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

This patch corresponds to review:
https://reviews.llvm.org/D26308

It adds a number of vector type conversion builtins to altivec.h.


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

Differential Revision: https://reviews.llvm.org/D26539

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

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

Summary:
Just like gcc, we should have the -Og option as more and more software are using it:
https://llvm.org/bugs/show_bug.cgi?id=20765

Reviewers: echristo, dberlin, dblaikie, keith.walker.arm, rengolin

Subscribers: aprantl, friss, mehdi_amini, RKSimon, probinson, majnemer, cfe-commits

Differential Revision: https://reviews.llvm.org/D24998

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

ExpectedFunctionGlobalVarMethodOrProperty
would previously say "functions and global variables"
instead of "functions, methods, properties, and global variables"

The newly added ExpectedFunctionOrGlobalVariable
says "functions and global variables"

Differential Revision: https://reviews.llvm.org/D26459

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

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

Clang emits error message for the following code:
```
template <class F> void parallel_loop(F &&f) { f(0); }

int main() {
  int x;
  parallel_loop([&](auto y) {
    {
      x = y;
    };
  });
}
```

$ clang++ --std=gnu++14 clang_test.cc -o clang_test
clang_test.cc:9:7: error: reference to local variable 'x' declared in enclosing function 'main'
      x = y;
            ^
clang_test.cc:2:48: note: in instantiation of function template specialization 'main()::(anonymous class)::operator()<int>' requested here
            template <class F> void parallel_loop(F &&f) { f(0); }
                                                           ^
clang_test.cc:6:3: note: in instantiation of function template specialization 'parallel_loop<(lambda at clang_test.cc:6:17)>' requested here parallel_loop([&](auto y) {
           ^
clang_test.cc:5:7: note: 'x' declared here
      int x;
          ^
1 error generated.

Patch fixes this issue.

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

The change in D26502 splits ReaderWriter.h, which contains the APIs
into both the BitReader and BitWriter libraries, into BitcodeReader.h
and BitcodeWriter.h.

Change clang uses to the appropriate split header(s).

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

Summary:
This macro should be defined only when the user directly specifies an
API level as part of an Android target. For any regular Android target,
we leave this macro undefined.

Bug: https://llvm.org/bugs/show_bug.cgi?id=30940

Reviewers: eugenis, pirama

Subscribers: tberghammer, cfe-commits, pirama, eugenis, danalbert

Differential Revision: https://reviews.llvm.org/D26491

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

Take 3! This should finally fix the Hexagon, PPC, and Windows bots.

rdar://problem/25846421

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

This reverts commit r286533. At this point an array really is still an
array, but the problem is with /non-/array va_lists anyway.

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

function. In that case, there is no requirement that the callee is actually
defined, and the code may in fact be valid and have defined behavior if the
virtual call is unreachable.


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

PowerPC's va_list, at least, is a typedef for an array, which means it
decays to a pointer in parameter position. Since the decayed type is
built from the array element type, the typedef sugar is lost.

More rdar://problem/25846421.

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

Platform headers don't always define 'va_list' in terms of Clang's
'__builtin_va_list', so in addition to checking for our own
synthesized decl, also just look for typedefs literally named
'va_list'. Better to err on the side of false negatives here.

Fix-up for rdar://problem/25846421.

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

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

There are many non-portable typedefs, but va_list is one that nobody
ever thinks of as a pointer or an array. (When's the last time you saw
someone check for a NULL va_list?) Make an exception for this one
special type.

Part of rdar://problem/25846421.

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

...or within a reference. Both of these add an extra level of
indirection that make us less certain that the pointer really was
supposed to be non-nullable. However, changing the default behavior
would be a breaking change, so we'll just make it a warning instead.

Part of rdar://problem/25846421

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

This is an addition to (and sub-warning of) -Wnullability-completeness
that warns when an array parameter is missing nullability. When the
specific warning is switched off, the compiler falls back to only
warning on pointer types written as pointer types.

Note that use of nullability /within/ an array triggers the
completeness checks regardless of whether or not the array-specific
warning is enabled; the intent there is simply to determine whether a
particular header is trying to be nullability-aware at all.

Part of rdar://problem/25846421.

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

Since array parameters decay to pointers, '_Nullable' and friends
should be available for use there as well. This is especially
important for parameters that are typedefs of arrays. The unsugared
syntax for this follows the syntax for 'static'-sized arrays in C:

  void test(int values[_Nullable]);

This syntax was previously accepted but the '_Nullable' (and any other
attributes) were silently discarded. However, applying '_Nullable' to
a typedef was previously rejected and is now accepted; therefore, it
may be necessary to test for the presence of this feature:

  #if __has_feature(nullability_on_arrays)

One important change here is that DecayedTypes don't always
immediately contain PointerTypes anymore; they may contain an
AttributedType instead. This only affected one place in-tree, so I
would guess it's not likely to cause problems elsewhere.

This commit does not change -Wnullability-completeness just yet. I
want to think about whether it's worth doing something special to
avoid breaking existing clients that compile with -Werror. It also
doesn't change '#pragma clang assume_nonnull' behavior, which
currently treats the following two declarations as equivalent:

  #pragma clang assume_nonnull begin
  void test(void *pointers[]);
  #pragma clang assume_nonnull end

  void test(void * _Nonnull pointers[]);

This is not the desired behavior, but changing it would break
backwards-compatibility. Most likely the best answer is going to be
adding a new warning.

Part of rdar://problem/25846421

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

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

This un-breaks the `check-clang` target.

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

Actual regression was introduced in r272668. This revision fixes JS script, but
also regress Cpp case. It manifests with spaces added when template is followed
with array. Bug 30527 mentions case of array as a nested template type
(foo<bar<baz>[]>). Fix is to detect such case and to prevent treating it as
array initialization, but as a subscript case. However, before r272668, this
case was treated simple because we were detecting it as a StartsObjCMethodExpr.
Same was true for other similar case - array of templates (foo<int>[]). This
patch tries to address two problems: 1) fixing regression 2) making sure both
cases (array as a nested type, array of templates) which were entering
StartsObjCMethodExpr branch are handled now appropriately.

https://reviews.llvm.org/D26163
Patch from Branko Kokanovic <branko@kokanovic.org>!


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

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

- EnterExpressionEvaluationContext allows you to specify whether you
  *actually* want to enter an evaluation context.
- For types that don't allow that, llvm::Optional<Foo> should do the
  same thing as std::unique_ptr<Foo>, but with 100% less heap
  allocations.


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

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

Expose a warning flag for warn_duplicate_protocol_def. This allows control
over the severity of duplicate protocol definitions.

For example -Werror=duplicate-protocol or
#pragma clang diagnostic ignored "-Wduplicate-protocol".

Patch provided by Dave Lee!

Differential Revision: https://reviews.llvm.org/D26406


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

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

Summary:
See TypeScript grammar for tokens following 'declare':
https://github.com/Microsoft/TypeScript/blob/master/doc/spec.md#A.10

Additional minor change:
clang-format: [JS] Prevent ASI before const.

Reviewers: djasper

Subscribers: cfe-commits, klimek

Differential Revision: https://reviews.llvm.org/D26274

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

See TypeScript grammar for tokens following 'declare':
https://github.com/Microsoft/TypeScript/blob/master/doc/spec.md#A.10

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

aren't captured by lambdas with a default capture specifier

This commit is a follow-up to r286354. It avoids the -Wshadow warning for
variables which shadow variables that aren't captured by lambdas with a default
capture specifier. It provides an additional note that points to location of
the capture.

The old behaviour is preserved with -Wshadow-all or -Wshadow-uncaptured-local.

rdar://14984176

Differential Revision: https://reviews.llvm.org/D26448


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

can be used to improve the locations when generating remarks for loops.

Depends on the companion LLVM change r286227.

Patch by Florian Hahn.

Differential Revision: https://reviews.llvm.org/D25764



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

Implement all the different 24 overloads for vec_xl and vec_xst.

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

Output generated by option -ast-print looks like C/C++ code, and it
really is for plain C. For C++ the produced output was not valid C++
code, but the differences were small. With this change the output
is fixed and can be compiled. Tests are changed so that output produced
by -ast-print is compiled again with the same flags and both outputs are
compared.

Option -ast-print is extensively used in clang tests but it itself
was tested poorly, existing tests only checked that compiler did not
crash. There are unit tests in file DeclPrinterTest.cpp, but they test
only terse output mode.

Differential Revision: https://reviews.llvm.org/D26452


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