Summary:
Given the following test program:

```
class C {
public:
  int A(int a, int& b);
};

int C::A(const int a, int b) {
  return a * b;
}
```

Clang would produce an error message that correctly diagnosed the
redeclaration of `C::A` to not match the original declaration (the
parameters to the two declarations do not match -- the original takes an
`int &` as its 2nd parameter, but the redeclaration takes an `int`). However,
it also produced a note diagnostic that inaccurately pointed to the
first parameter, claiming that `const int` in the redeclaration did not
match the unqualified `int` in the original. The diagnostic is
misleading because it has nothing to do with why the program does not
compile.

The logic for checking for a function overload, in
`Sema::FunctionParamTypesAreEqual`, discards cv-qualifiers before
checking whether the types are equal. Do the same when producing the
overload diagnostic.

Reviewers: rsmith

Reviewed By: rsmith

Subscribers: cpplearner, cfe-commits

Tags: #clang

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

llvm-svn: 352831

Summary:
UBSan wants to detect when unreachable code is actually reached, so it
adds instrumentation before every unreachable instruction. However, the
optimizer will remove code after calls to functions marked with
noreturn. To avoid this UBSan removes noreturn from both the call
instruction as well as from the function itself. Unfortunately, ASan
relies on this annotation to unpoison the stack by inserting calls to
_asan_handle_no_return before noreturn functions. This is important for
functions that do not return but access the the stack memory, e.g.,
unwinder functions *like* longjmp (longjmp itself is actually
"double-proofed" via its interceptor). The result is that when ASan and
UBSan are combined, the noreturn attributes are missing and ASan cannot
unpoison the stack, so it has false positives when stack unwinding is
used.

Changes:
Clang-CodeGen now directly insert calls to `__asan_handle_no_return`
when a call to a noreturn function is encountered and both
UBsan-unreachable and ASan are enabled. This allows UBSan to continue
removing the noreturn attribute from functions without any changes to
the ASan pass.

Previously generated code:
```
  call void @longjmp
  call void @__asan_handle_no_return
  call void @__ubsan_handle_builtin_unreachable
```

Generated code (for now):
```
  call void @__asan_handle_no_return
  call void @longjmp
  call void @__asan_handle_no_return
  call void @__ubsan_handle_builtin_unreachable
```

rdar://problem/40723397

Reviewers: delcypher, eugenis, vsk

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

> llvm-svn: 352690

llvm-svn: 352829

Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc
doesn't choke on it, hopefully.

Original Message:
The FunctionCallee type is effectively a {FunctionType*,Value*} pair,
and is a useful convenience to enable code to continue passing the
result of getOrInsertFunction() through to EmitCall, even once pointer
types lose their pointee-type.

Then:
- update the CallInst/InvokeInst instruction creation functions to
  take a Callee,
- modify getOrInsertFunction to return FunctionCallee, and
- update all callers appropriately.

One area of particular note is the change to the sanitizer
code. Previously, they had been casting the result of
`getOrInsertFunction` to a `Function*` via
`checkSanitizerInterfaceFunction`, and storing that. That would report
an error if someone had already inserted a function declaraction with
a mismatching signature.

However, in general, LLVM allows for such mismatches, as
`getOrInsertFunction` will automatically insert a bitcast if
needed. As part of this cleanup, cause the sanitizer code to do the
same. (It will call its functions using the expected signature,
however they may have been declared.)

Finally, in a small number of locations, callers of
`getOrInsertFunction` actually were expecting/requiring that a brand
new function was being created. In such cases, I've switched them to
Function::Create instead.

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

llvm-svn: 352827

Having an incorrect type for a cast causes the checker to incorrectly
dismiss the operation under ARC, leading to a false positive
use-after-release on the test.

rdar://47709885

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

llvm-svn: 352824

This reverts commit r350920 as it is not clear whether we should force a
class to be returned in registers when copy and move constructors are
both deleted.

For more background, see the following discussion:
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20190128/259907.html

llvm-svn: 352822

- fixes the test on macOS with LLVM_ENABLE_PIC=OFF
- together with D57343, gets the test to pass on Windows
- makes it run everywhere (it seems to just pass on Linux)

The main change is to pull out the resource directory computation into a
function shared by all 3 places that do it. In CIndexer.cpp, this now works no
matter if libclang is in lib/ or bin/ or statically linked to a binary in bin/.


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

llvm-svn: 352803

rC352620 caused regressions because it copied floating point format from
aux target.

floating point format decides whether extended long double is supported.
It is x86_fp80 on x86 but IEEE double on amdgcn.

Document usage of long doubel type in HIP programming guide 
https://github.com/ROCm-Developer-Tools/HIP/pull/890

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

llvm-svn: 352801

This reverts commit f47d6b38 (r352791).

Seems to run into compilation failures with GCC (but not clang, where
I tested it). Reverting while I investigate.

llvm-svn: 352800

Instead of calling CUDA runtime to arrange function arguments,
the new API constructs arguments in a local array and the kernels
are launched with __cudaLaunchKernel().

The old API has been deprecated and is expected to go away
in the next CUDA release.

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

llvm-svn: 352799

..and use it to control that parts of CUDA compilation
that depend on the specific version of CUDA SDK.

This patch has a placeholder for a 'new launch API' support
which is in a separate patch. The list will be further
extended in the upcoming patch to support CUDA-10.1.

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

llvm-svn: 352798

Summary: Also clean up some preexisting target feature code.

Reviewers: aheejin

Subscribers: dschuff, sbc100, jgravelle-google, hiraditya, sunfish, jfb

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

llvm-svn: 352793

The FunctionCallee type is effectively a {FunctionType*,Value*} pair,
and is a useful convenience to enable code to continue passing the
result of getOrInsertFunction() through to EmitCall, even once pointer
types lose their pointee-type.

Then:
- update the CallInst/InvokeInst instruction creation functions to
  take a Callee,
- modify getOrInsertFunction to return FunctionCallee, and
- update all callers appropriately.

One area of particular note is the change to the sanitizer
code. Previously, they had been casting the result of
`getOrInsertFunction` to a `Function*` via
`checkSanitizerInterfaceFunction`, and storing that. That would report
an error if someone had already inserted a function declaraction with
a mismatching signature.

However, in general, LLVM allows for such mismatches, as
`getOrInsertFunction` will automatically insert a bitcast if
needed. As part of this cleanup, cause the sanitizer code to do the
same. (It will call its functions using the expected signature,
however they may have been declared.)

Finally, in a small number of locations, callers of
`getOrInsertFunction` actually were expecting/requiring that a brand
new function was being created. In such cases, I've switched them to
Function::Create instead.

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

llvm-svn: 352791

Preferred types are used by code completion for ranking. This commit
considerably increases the number of points in code where those types
are propagated.

In order to avoid complicating signatures of Parser's methods, a
preferred type is kept as a member variable in the parser and updated
during parsing.

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

llvm-svn: 352788

This reverts commit r352690. This causes clang to crash. Sent reproducer to the
author in the orginal commit.

llvm-svn: 352755

This reverts commit 352740: broke swift build

llvm-svn: 352748

Summary:
As PR17480 describes, clang does not support the used attribute
for member functions of class templates. This means that if the member
function is not used, its definition is never instantiated. This patch
changes clang to emit the definition if it has the used attribute.

Test Plan: Added a testcase

Reviewed By: aaron.ballman

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

llvm-svn: 352740

This reverts commits r352729 and r352731: this broke Sanitizer Windows bots

llvm-svn: 352733

Previously, there were two different scripts for generating VCS headers:
one used by LLVM and one used by Clang. They were both similar, but
different. They were both broken in their own ways, for example the one
used by Clang didn't properly handle monorepo resulting in an incorrect
version information reported by Clang.

This change unifies two the scripts by introducing a new script that's
used from both LLVM and Clang, ensures that the new script supports both
monorepo and standalone SVN and Git setups, and removes the old scripts.

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

llvm-svn: 352729

Summary:
UBSan wants to detect when unreachable code is actually reached, so it
adds instrumentation before every unreachable instruction. However, the
optimizer will remove code after calls to functions marked with
noreturn. To avoid this UBSan removes noreturn from both the call
instruction as well as from the function itself. Unfortunately, ASan
relies on this annotation to unpoison the stack by inserting calls to
_asan_handle_no_return before noreturn functions. This is important for
functions that do not return but access the the stack memory, e.g.,
unwinder functions *like* longjmp (longjmp itself is actually
"double-proofed" via its interceptor). The result is that when ASan and
UBSan are combined, the noreturn attributes are missing and ASan cannot
unpoison the stack, so it has false positives when stack unwinding is
used.

Changes:
Clang-CodeGen now directly insert calls to `__asan_handle_no_return`
when a call to a noreturn function is encountered and both
UBsan-unreachable and ASan are enabled. This allows UBSan to continue
removing the noreturn attribute from functions without any changes to
the ASan pass.

Previously generated code:
```
  call void @longjmp
  call void @__asan_handle_no_return
  call void @__ubsan_handle_builtin_unreachable
```

Generated code (for now):
```
  call void @__asan_handle_no_return
  call void @longjmp
  call void @__asan_handle_no_return
  call void @__ubsan_handle_builtin_unreachable
```

rdar://problem/40723397

Reviewers: delcypher, eugenis, vsk

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

llvm-svn: 352690

objc_alloc and objc_allocWithZone may throw exceptions if the
underlying method does. If we're in a @try block, then make sure we
emit an invoke instead of a call.

rdar://47610407

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

llvm-svn: 352687

This API will be extracted into a new template class.  This change will
make the follow-up commit easier to review.

llvm-svn: 352676

required.

Function __kmpc_push_target_tripcount should be emitted only if the
offloading entry is going to be emitted (for use in tgt_target...
functions). Otherwise, it should not be emitted.

llvm-svn: 352669

This builtin has the same UI as __builtin_object_size, but has the
potential to be evaluated dynamically. It is meant to be used as a
drop-in replacement for libraries that use __builtin_object_size when
a dynamic checking mode is enabled. For instance,
__builtin_object_size fails to provide any extra checking in the
following function:

  void f(size_t alloc) {
    char* p = malloc(alloc);
    strcpy(p, "foobar"); // expands to __builtin___strcpy_chk(p, "foobar", __builtin_object_size(p, 0))
  }

This is an overflow if alloc < 7, but because LLVM can't fold the
object size intrinsic statically, it folds __builtin_object_size to
-1. With __builtin_dynamic_object_size, alloc is passed through to
__builtin___strcpy_chk.

rdar://32212419

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

llvm-svn: 352665

This is meant to be used with clang's __builtin_dynamic_object_size.
When 'true' is passed to this parameter, the intrinsic has the
potential to be folded into instructions that will be evaluated
at run time. When 'false', the objectsize intrinsic behaviour is
unchanged.

rdar://32212419

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

llvm-svn: 352664

This will make follow-up changes easier to review.

llvm-svn: 352663

This will make follow-up commits easier to review.

llvm-svn: 352661

This is consistent with the TextNodeDumper, and is the appropriate name
for the traverser class which will be extracted.

llvm-svn: 352657

This was a porting aid.

llvm-svn: 352656

Reviewers: aaron.ballman

Subscribers: jfb, cfe-commits

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

llvm-svn: 352655

Summary:
Was trying to understand how complicated it would be to write
a clang-tidy `openmp-exception-escape`-ish check once D57100 lands.

Just so it happens, all the data is already there,
it is just conveniently omitted from AST dump.

Reviewers: aaron.ballman, steveire, ABataev

Reviewed By: ABataev

Subscribers: ABataev, guansong, cfe-commits

Tags: #openmp, #clang

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

llvm-svn: 352631

Summary:
> $ echo "int c = [b]() mutable noexcept { return [&b] { return b++; }(); }();" |clang-format

```
int c = [b]() mutable noexcept {
  return [&b] { return b++; }();
}
();
```
with patch:
> $ echo "int c = [b]() mutable noexcept { return [&b] { return b++; }(); }();" |bin/clang-format
```
int c = [b]() mutable noexcept { return [&b] { return b++; }(); }();
```

Contributed by hultman.

Reviewers: benhamilton, jolesiak, klimek, Wizard

Reviewed By: benhamilton

Subscribers: cfe-commits

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

llvm-svn: 352622

In 64 bit MSVC environment size_t is defined as unsigned long long.
In single source language like HIP, data layout should be consistent
in device and host compilation, therefore copy data layout controlling
fields from Aux target for AMDGPU target.

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

llvm-svn: 352620

When creating the prototype of implicit assignment operators the
returned reference to the class should be qualified with the same
addr space as 'this' (i.e. __generic in OpenCL).

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

llvm-svn: 352617

Append appropriate -rpath when using shared compiler-rt runtimes,
e.g. '-fsanitize=address -shared-libasan'.  There's already a similar
logic in CommonArgs.cpp but it uses non-standard arch-suffixed
installation directory while we want our driver to work with standard
installation paths.

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

llvm-svn: 352610

Use the real_path implementation from llvm::sys::fs::real_path instead
of having a custom implementation in the ModuleDependencyCollector.

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

llvm-svn: 352605

llvm-svn: 352595

No functionality change intended.

llvm-svn: 352593

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

llvm-svn: 352588

Provide a more powerful and at the same time more readable way of specifying
taint propagation rules for known functions within the checker.

Now it should be possible to specify an unlimited amount of source and
destination parameters for taint propagation.

No functional change intended just yet.

Patch by Gábor Borsik!

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

llvm-svn: 352572

Reviewers: aaron.ballman

Subscribers: cfe-commits

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

llvm-svn: 352558