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

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

Use more descriptive name for the method qualifiers getter.

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

llvm-svn: 352349

declaration in MSVCCompat mode

Microsoft compiler permits the use of 'static' storage specifier outside
of a class definition if it's on an out-of-line member function template
declaration.

This patch allows 'static' storage specifier on an out-of-line member
function template declaration with a warning in Clang (To be compatible
with Microsoft).

Intel C/C++ compiler allows the 'static' keyword with a warning in
Microsoft mode. GCC allows this with -fpermissive.

Patch By: Manna

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

Change-Id: I97b2d9e9d57cecbcd545d17e2523142a85ca2702
llvm-svn: 352219

attributes from declaration over attributes from '#pragma clang attribute'

Before this commit users had an issue when using #pragma clang attribute with
availability attributes:

The explicit attribute that's specified next to the declaration is not
guaranteed to be preferred over the attribute specified in the pragma.

This commit fixes this by introducing a priority field to the availability
attribute to control how they're merged. Attributes with higher priority are
applied over attributes with lower priority for the same platform. The
implicitly inferred attributes are given the lower priority. This ensures that:

- explicit attributes are preferred over all other attributes.
- implicitly inferred attributes that are inferred from an explicit attribute
  are discarded if there's an explicit attribute or an attribute specified
  using a #pragma for the same platform.
- implicitly inferred attributes that are inferred from an attribute in the
  #pragma are not used if there's an explicit, explicit #pragma, or an
  implicit attribute inferred from an explicit attribute for the declaration.

This is the resulting ranking:

`platform availability > platform availability from pragma > inferred availability > inferred availability from pragma`

rdar://46390243

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

llvm-svn: 352084

before adding a delayed diagnostic to DelayedDiagnostics.

This fixes an assertion failure in Sema::DelayedDiagnostics::add that
was caused by the changes made in r141037.

rdar://problem/42782323

llvm-svn: 351911

to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

  With commit r351627, LLVM gained the ability to apply (existing) IPO
  optimizations on indirections through callbacks, or transitive calls.
  The general idea is that we use an abstraction to hide the middle man
  and represent the callback call in the context of the initial caller.
  It is described in more detail in the commit message of the LLVM patch
  r351627, the llvm::AbstractCallSite class description, and the
  language reference section on callback-metadata.

  This commit enables clang to emit !callback metadata that is
  understood by LLVM. It does so in three different cases:
    1) For known broker functions declarations that are directly
       generated, e.g., __kmpc_fork_call for the OpenMP pragma parallel.
    2) For known broker functions that are identified by their name and
       source location through the builtin detection, e.g.,
       pthread_create from the POSIX thread API.
    3) For user annotated functions that carry the "callback(callee, ...)"
       attribute. The attribute has to include the name, or index, of
       the callback callee and how the passed arguments can be
       identified (as many as the callback callee has). See the callback
       attribute documentation for detailed information.

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

llvm-svn: 351629

As of r343360, we support fixed-enums in C. This lead to some
warnings in project headers where a fixed enum is forward declared
then later defined. In C++, this is fine, the forward declaration is
treated as a complete type even though the definition isn't present.
We use this rule in C too, but still warn about the forward
declaration anyways. This patch suppresses the warning.

rdar://problem/47356469

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

llvm-svn: 351595

Summary:
This attribute will allow users to opt specific functions out of
speculative load hardening. This compliments the Clang attribute
named speculative_load_hardening. When this attribute or the attribute
speculative_load_hardening is used in combination with the flags
-mno-speculative-load-hardening or -mspeculative-load-hardening,
the function level attribute will override the default during LLVM IR
generation. For example, in the case, where the flag opposes the
function attribute, the function attribute will take precendence.
The sticky inlining behavior of the speculative_load_hardening attribute
may cause a function with the no_speculative_load_hardening attribute
to be tagged with the speculative_load_hardening tag in
subsequent compiler phases which is desired behavior since the
speculative_load_hardening LLVM attribute is designed to be maximally
conservative.

If both attributes are specified for a function, then an error will be
thrown.

Reviewers: chandlerc, echristo, kristof.beyls, aaron.ballman

Subscribers: llvm-commits

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

llvm-svn: 351565

r347812 permitted forward declarations for cpu-dispatch functions, which
are occassionally useful as exposition in  header files.  However, this inadvertently
permitted this function to become multiversioned after a usage.  This
patch ensures that the "CausesMV" checks are still run in the
forward-declaration case.

Change-Id: Icb6f975a2d068f088b89e3bbe26cf1d24f5a972c
llvm-svn: 351212

Set address spaces of 'this' param correctly for implicit special
class members.

This also changes initialization conversion sequence to separate
address space conversion from other qualifiers in case of binding
reference to a temporary. In this case address space conversion  
should happen after the binding (unlike for other quals). This is
needed to materialize it correctly in the alloca address space.

Initial patch by Mikael Nilssoni!

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

llvm-svn: 351053

variable during auto type deduction, use the rewritten initializer when
performing initialization of the variable.

This silences spurious -Warc-repeated-use-of-weak warnings that are
issued when the initializer uses a weak ObjC pointer.

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

llvm-svn: 350917

function declaration.

We'd previously often just drop these on the floor, and friend
redeclaration matching would usually (but not always) figure out the
right redeclaration anyway.

Also, don't try to match a dependent friend function template
specialization to a template until instantiation, and don't forget to
reject qualified friend declarations in dependent contexts that don't
name an already-declared entity.

llvm-svn: 350915

Rather than duplicating data fields, use DeclSpec directly to store
the qualifiers for the functions/methods. This change doesn't handle
attributes yet and has to be extended further.

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

llvm-svn: 350703

template specialization if there is no matching non-template function.

This exposed a couple of related bugs:
 - we would sometimes substitute into a friend template instead of a
   suitable non-friend declaration; this would now crash because we'd
   decide the specialization of the friend is a redeclaration of itself
 - ADL failed to properly handle the case where an invisible local
   extern declaration redeclares an invisible friend

Both are fixed herein: in particular, we now never make invisible
friends or local extern declarations visible to name lookup unless
they are the only declaration of the entity. (We already mostly did
this for local extern declarations.)

llvm-svn: 350505

Rather than sprinkle calls to DiagnoseUnusedExprResult() around in places where we want diagnostics, we now diagnose unused expression statements and full expressions in a more generic way when acting on the final expression statement. This results in more appropriate diagnostics for [[nodiscard]] where we were previously lacking them, such as when the body of a for loop is not a compound statement.

This patch fixes PR39837.

llvm-svn: 350404

The AST context is already easily available. NFC.

llvm-svn: 349904

Address spaces are cast into generic before invoking the constructor.

Added support for a trailing Qualifiers object in FunctionProtoType.

Note: This recommits the previously reverted patch, 
      but now it is commited together with a fix for lldb.

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

llvm-svn: 349019

Reverting because the patch broke lldb.

llvm-svn: 348931

Address spaces are cast into generic before invoking the constructor.

Added support for a trailing Qualifiers object in FunctionProtoType.

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

llvm-svn: 348927

Summary: Found via `codespell -q 3 -I ../clang-whitelist.txt -L uint,importd,crasher,gonna,cant,ue,ons,orign,ned`

Reviewers: teemperor

Reviewed By: teemperor

Subscribers: teemperor, jholewinski, jvesely, nhaehnle, whisperity, jfb, cfe-commits

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

llvm-svn: 348755

Friend function template defined in a class template becomes available if
the enclosing class template is instantiated. Until the function template
is used, it does not have a body, but still is considered a definition for
the purpose of redeclaration checks.

This change modifies redefinition check so that it can find the friend
function template definitions in instantiated classes.

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

llvm-svn: 348473

[Sema] Push and Pop Expression Evaluation Context Records at the start and end of function definitions

This patch creates a new context for every function definition we enter.
Currently we do not push and pop on these, usually working off of the global
context record added in the Sema constructor, which never gets popped.

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

llvm-svn: 348434

We would issue a false-positive diagnostic for parameters in function declarations shadowing fields; we now only issue the diagnostic on a function definition instead.

llvm-svn: 348400

headers.

Previously, we would only check whether the new declaration is in a
system header, but that requires the user to be able to correctly guess
whether a declaration in a system header is declared as a struct or a
class when specializing standard library traits templates.

We now entirely ignore declarations for which the warning was disabled
when determining whether to warn on a tag mismatch.

Also extend the diagnostic message to clarify that
 a) code containing such a tag mismatch is in fact valid and correct,
    and
 b) the (non-coding-style) reason to emit such a warning is that the
    Microsoft C++ ABI is broken and includes the tag kind in decorated
    names,
as it seems a lot of users are confused by our diagnostic here (either
not understanding why we produce it, or believing that it represents an
actual language rule).

llvm-svn: 348233

It seems the two failing tests can be simply fixed after r348037

Fix 3 cases in Analysis/builtin-functions.cpp
Delete the bad CodeGen/builtin-constant-p.c for now

llvm-svn: 348053

Kept the "indirect_builtin_constant_p" test case in test/SemaCXX/constant-expression-cxx1y.cpp
while we are investigating why the following snippet fails:

  extern char extern_var;
  struct { int a; } a = {__builtin_constant_p(extern_var)};

llvm-svn: 348039

Fix ICEs on template instantiations that were leading to
the creation of invalid code patterns with address spaces.

Incorrect cases are now diagnosed properly.

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

llvm-svn: 347865

As a followup to r347805, allow forward declarations of cpu-dispatch and
cpu-specific for the same reasons.

Change-Id: Ic1bde9be369b1f8f1d47d58e6fbdc2f9dfcdd785
llvm-svn: 347812

Declarations without the attribute were disallowed because it would be
ambiguous which 'target' it was supposed to be on.  For example:

void ___attribute__((target("v1"))) foo();
void foo(); // Redecl of above, or fwd decl of below?
void ___attribute__((target("v2"))) foo();

However, a first declaration doesn't have that problem, and erroring
prevents it from working in cases where the forward declaration is
useful.

Additionally, a forward declaration of target==default wouldn't properly
cause multiversioning, so this patch fixes that.

The patch was not split since the 'default' fix would require
implementing the same check for that case, followed by undoing the same
change for the fwd-decl implementation.

Change-Id: I66f2c5bc2477bcd3f7544b9c16c83ece257077b0
llvm-svn: 347805

CodeGen

Change-Id: I32b14edca3501277e0e65672eafe3eea38c6f9ae
llvm-svn: 347791

This was reverted in r347656 due to me thinking it caused a miscompile of
Chromium. Turns out it was the Chromium code that was broken.

llvm-svn: 347756

This caused a miscompile in Chrome (see crbug.com/908372) that's
illustrated by this small reduction:

  static bool f(int *a, int *b) {
    return !__builtin_constant_p(b - a) || (!(b - a));
  }

  int arr[] = {1,2,3};

  bool g() {
    return f(arr, arr + 3);
  }

  $ clang -O2 -S -emit-llvm a.cc -o -

g() should return true, but after r347417 it became false for some reason.

This also reverts the follow-up commits.

r347417:
> Re-Reinstate 347294 with a fix for the failures.
>
> Don't try to emit a scalar expression for a non-scalar argument to
> __builtin_constant_p().
>
> Third time's a charm!

r347446:
> The result of is.constant() is unsigned.

r347480:
> A __builtin_constant_p() returns 0 with a function type.

r347512:
> isEvaluatable() implies a constant context.
>
> Assume that we're in a constant context if we're asking if the expression can
> be compiled into a constant initializer. This fixes the issue where a
> __builtin_constant_p() in a compound literal was diagnosed as not being
> constant, even though it's always possible to convert the builtin into a
> constant.

r347531:
> A "constexpr" is evaluated in a constant context. Make sure this is reflected
> if a __builtin_constant_p() is a part of a constexpr.

llvm-svn: 347656

Don't try to emit a scalar expression for a non-scalar argument to
__builtin_constant_p().

Third time's a charm!

llvm-svn: 347417

llvm-svn: 347389

EvaluateAsInt() is sometimes called in a constant context. When that's the
case, we need to specify it as so.

llvm-svn: 347364

Added references to the addr spaces deduction and enabled
CL2.0 features (program scope variables and storage class
qualifiers) to work in C++ mode too.

Fixed several address space conversion issues in CodeGen 
for references.

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

llvm-svn: 347059

Summary:
This CL adds /Zc:DllexportInlines flag to clang-cl.
When Zc:DllexportInlines- is specified, inline class member function is not exported if the function does not have local static variables.

By not exporting inline function, code for those functions are not generated and that reduces both compile time and obj size. Also this flag does not import inline functions from dllimported class if the function does not have local static variables.

On my 24C48T windows10 machine, build performance of chrome target in chromium repository is like below.
These stats are come with 'target_cpu="x86" enable_nacl = false is_component_build=true dcheck_always_on=true` build config and applied
* https://chromium-review.googlesource.com/c/chromium/src/+/1212379
* https://chromium-review.googlesource.com/c/v8/v8/+/1186017

Below stats were taken with this patch applied on https://github.com/llvm-project/llvm-project-20170507/commit/a05115cd4c57ff76b0f529e38118765b58ed7f2e

| config                          | build time | speedup | build dir size |
| with patch, PCH on, debug       | 1h10m0s    | x1.13   | 35.6GB         |
| without patch, PCH on, debug    | 1h19m17s   |         | 49.0GB         |
| with patch, PCH off, debug      | 1h15m45s   | x1.16   | 33.7GB         |
| without patch, PCH off, debug   | 1h28m10s   |         | 52.3GB         |
| with patch, PCH on, release     | 1h13m13s   | x1.22   | 26.2GB         |
| without patch, PCH on, release  | 1h29m57s   |         | 37.5GB         |
| with patch, PCH off, release    | 1h23m38s   | x1.32   | 23.7GB         |
| without patch, PCH off, release | 1h50m50s   |         | 38.7GB         |

This patch reduced obj size and the number of exported symbols largely, that improved link time too.
e.g. link time stats of blink_core.dll become like below
|                              | cold disk cache | warm disk cache |
| with patch, PCH on, debug    | 71s             | 30s             |
| without patch, PCH on, debug | 111s            | 48s             |

This patch's implementation is based on Nico Weber's patch. I modified to support static local variable, added tests and took stats.

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

Reviewers: hans, thakis, rnk, javed.absar

Reviewed By: hans

Subscribers: kristof.beyls, smeenai, dschuff, probinson, cfe-commits, eraman

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

llvm-svn: 346069

This addresses PR34120. Note, unlike GCC, we take into account the accessibility of the field when deciding whether to warn or not.

llvm-svn: 346041