Reviewers: ioeric

Reviewed By: ioeric

Subscribers: klimek, cfe-commits, mgorny

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

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

Reviewers: ioeric

Reviewed By: ioeric

Subscribers: klimek, cfe-commits

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

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

Ensure that we check the ivar containing decl for the DLL storage
attribute rather than the ivar itself as the dll storage is associated
to the interface decl not the ivar decl.

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

This is nedeeded for the toolchain to be actually usable as a host
toolchain on Darwin.

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

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

This includes the clang-refactor in the toolchain distribution.

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

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

This allows including clang-refactor in LLVM_DISTRIBUTION_COMPONENTS
to build clang-refactor as part of the toolchain distribution.

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

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

to aid clang-tidy comprehension.
Requested by @alexfh in https://reviews.llvm.org/D39015

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

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

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

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

Move utilities functions into a separate file to make comprehension
easier.

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

Pointer to HTML diagnostics is removed (as it is not stored) as well as
the version (as it would be available from the commit message).

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

determining whether a RecordDecl is CFError.

CFErrorRef used to be declared with "objc_bridge(NSError)" but is now
declared with "objc_bridge_mutable(NSError)". Look for either when
checking whether a RecordDecl is CFError.

rdar://problem/35034779

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

Fastcall doesn't support variadic function calls, so
setting the default calling convention to Fastcall would
result in incorrect code being emitted for these conditions.

This patch adds a 'variadic' test to the default calling conv
test, as well as fixes the behavior of fastcall.


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

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

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

A helper builtin to facilitate implementing the
std::has_unique_object_representations type trait.

Requested here: https://bugs.llvm.org/show_bug.cgi?id=34942
Also already exists in GCC and MSVC.

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


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

rL316268 / D39122 has fixed PR35009, and now when in C,
these three(?) diagnostics properly use the enum's underlying
datatype.

While it was fixed, the test coverage was clearly insufficient,
because the -Wsign-compare change didn't show up in any of the
tests, until it was reported in the post-commit mail for rL316268.

So add the test for the -Wsign-compare diagnostic for enum
for C code, and while there, document this in the release notes.

The fix itself was obviously correct, so unless we want to silence
this new diagnosed case, i deem this commit to be NFC.

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

Fixed passing of VLAs and variably-modified types to outlined functions.
Synchronized passing with the types codegen.

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

Builder save/restores insertion pointer when emitting addr space cast
for alloca, but does not save/restore debug loc, which causes verifier
failure for certain call instructions.

This patch fixes that.

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


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

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

This commit adds an initial, skeleton outline of the "extract function"
refactoring. The extracted function doesn't capture variables / rewrite code
yet, it just basically does a simple copy-paste.
The following initiation rules are specified:

- extraction can only be done for executable code in a function/method/block.
  This means that you can't extract a global variable initialize into a function
  right now.
- simple literals and references are not extractable.

This commit also adds support for full source ranges to clang-refactor's test
mode.

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


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

'-'/'+' prefix

rdar://12040840


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

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

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

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

Addendum to differential revision: https://reviews.llvm.org/D39127


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

With enabled CINDEXTEST_CODE_COMPLETE_PATTERNS env option (which enables
IncludeCodePatterns in completion options) code completion after colon
currently suggests access modifiers with 2 completion chunks which is
incorrect.

Example:
class A : <Cursor>B
{
}

Currently we get 'NotImplemented:{TypedText public}{Colon :} (40)'
but the correct line is just 'NotImplemented:{TypedText public} (40)'

The fix introduces more specific scope that occurs between ':' and '{'
It allows us to determine when we don't need to add ':' as a second
chunk to the public/protected/private access modifiers.

Patch by Ivan Donchevskii!

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



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

Summary: This returns error instead of exiting the program in case of error.

Reviewers: klimek, hokein

Reviewed By: hokein

Subscribers: cfe-commits

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

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

When -mtune is used on AArch64 the -target-cpu is passed the value of the
cpu given to -mtune. As well as setting micro-architectural features of the
-mtune cpu, this will also add the architectural features such as support
for instructions. This can result in the backend using instructions that
are supported in the -mtune cpu but not supported in the target
architecture. For example use of the v8.1-a LSE extensions with -march=v8.
    
This change removes the setting of -target-cpu for -mtune, the -mcpu must
be used to set -target-cpu. This has the effect of removing all non-hard
coded benefits of mtune but it does produce correct output when -mtune cpu
with a later architecture than v8 is used.
    
Fixes PR34625
    
Differential Revision: https://reviews.llvm.org/D39179




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

Lit tries to inject the shared library paths, but no action is taken
when platform.system() is not recognized, results in an environment
variable with an empty name, which is illegal.

The patch fixes this mechanism for FreeBSD and NetBSD, and gives an
warning on other platforms, so that the latecomers don't have to spend
time on debugging lit.

Thanks Zhihao Yuan for the patch!

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

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

C++14 [dcl.constexpr]p4 states that in the body of a constexpr
constructor,

> every non-variant non-static data member and base class sub-object
  shall be initialized

However, [class.bit]p2 notes that

> Unnamed bit-fields are not members and cannot be initialized.

Therefore, we should make sure to filter them out of the check that
all fields are initialized.

Fixing this makes the constant evaluator a bit smarter, and
specifically allows constexpr constructors to avoid tripping
-Wglobal-constructors when the type contains unnamed bitfields.

Reviewed at https://reviews.llvm.org/D39035.

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

This bug was found via self-build on lld, and worked around
here: https://reviews.llvm.org/rL316180

The issue is that the 'using' causes the lookup to pick up the
first decl. However, when setting inherited default parameters,
we only update 'forward', not 'backward'. SO, only the newest param
list has all the information about the default arguments.

This patch ensures that the list of parameters we look through checks
the newest decl's template parameter list so it doesn't miss a default.

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


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

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

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

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

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

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

In getLValueElement Base may represent the address of a label 
(as in the newly-added test case), in this case it's not a loc::MemRegionVal 
and Base.castAs<loc::MemRegionVal>() triggers an assert, this diff makes 
getLValueElement return UnknownVal instead.

Differential revision: https://reviews.llvm.org/D39174


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

Allow Obj-C ivars with incomplete array type but only as the last ivar.
Also add a requirement for ivars that contain a flexible array member to
be at the end of class too. It is possible to add in a subclass another
ivar at the end but we'll emit a warning in this case. Also we'll emit a
warning if a variable sized ivar is declared in class extension or in
implementation because subclasses won't know they should avoid adding
new ivars.

In ARC incomplete array objects are treated as __unsafe_unretained so
require them to be marked as such.

Prohibit synthesizing ivars with flexible array members because order of
synthesized ivars is not obvious and tricky to control. Spelling out
ivar explicitly gives control to developers and helps to avoid surprises
with unexpected ivar ordering.

For C and C++ changed diagnostic to tell explicitly a field is not the
last one and point to the next field. It is not as useful as in Obj-C
but it is an improvement and it is consistent with Obj-C. For C for
unions emit more specific err_flexible_array_union instead of generic
err_field_incomplete.

rdar://problem/21054495

Reviewers: rjmccall, theraven

Reviewed By: rjmccall

Subscribers: cfe-commits

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



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

Passing a flavor to LLD requires command line argument, but if these
are being passed through a response file, this will fail because LLD
needs to know which driver to use before processing the response file.
Use ld.lld directly instead to avoid this issue.

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

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

In some cases the compiler can deduce the length of an array section
as constants. With this information, VLAs can be avoided in place of
a constant sized array or even a scalar value if the length is 1.
Example:
int a[4], b[2];
pragma omp parallel reduction(+: a[1:2], b[1:1])
{ }

For chained array sections, this optimization is restricted to cases
where all array sections except the last have a constant length 1.
This trivially guarantees that there are no holes in the memory region
that needs to be privatized.
Example:
int c[3][4];
pragma omp parallel reduction(+: c[1:1][1:2])
{ }

This relands commit r316229 that I reverted in r316235 because it
failed on some bots. During investigation I found that this was because
Clang and GCC evaluate the two arguments to emplace_back() in
ReductionCodeGen::emitSharedLValue() in a different order, hence
leading to a different order of generated instructions in the final
LLVM IR. Fix this by passing in the arguments from temporary variables
that are evaluated in a defined order.

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

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

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


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