------------------------------------------------------------------------
r293360 | gbiv | 2017-01-27 18:19:40 -0800 (Fri, 27 Jan 2017) | 11 lines

Change how we handle diagnose_if attributes.

This patch changes how we handle argument-dependent `diagnose_if`
attributes. In particular, we now check them in the same place that we
check for things like passing NULL to Nonnull args, etc. This is
basically better in every way than how we were handling them before. :)

This fixes PR31638, PR31639, and PR31640.

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

------------------------------------------------------------------------
Merging r293369:
------------------------------------------------------------------------
r293369 | gbiv | 2017-01-27 20:16:32 -0800 (Fri, 27 Jan 2017) | 7 lines

Attempt to unbreak buildbots.

r293360 broke some ARM bots, because size_t on those targets is
apparently `unsigned int`, not `unsigned long`. `sizeof(whatever)`
should to give us a `size_t`, so we can just use the type of that
instead.

------------------------------------------------------------------------


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

------------------------------------------------------------------------
r292497 | arphaman | 2017-01-19 09:17:57 -0800 (Thu, 19 Jan 2017) | 6 lines

[Sema] Fix PR28181 by avoiding calling BuildOverloadedBinOp in C mode

rdar://28532840

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

------------------------------------------------------------------------


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

[cxx1z-constexpr-lambda] [NFC] Add a FIXME to reinstate certain restrictions on constexpr lambdas from appearing within function-signatures (CWG1607)

For further background, see Richard's comments: http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20170109/181998.html

A patch to fix this is being worked on.

Thanks!


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

`diagnose_if` can be used to have clang emit either warnings or errors
for function calls that meet user-specified conditions. For example:

```
constexpr int foo(int a)
  __attribute__((diagnose_if(a > 10, "configurations with a > 10 are "
                                      "expensive.", "warning")));

int f1 = foo(9);
int f2 = foo(10); // warning: configuration with a > 10 are expensive.
int f3 = foo(f2);
```

It currently only emits diagnostics in cases where the condition is
guaranteed to always be true. So, the following code will emit no
warnings:

```
constexpr int bar(int a) {
  foo(a);
  return 0;
}

constexpr int i = bar(10);
```

We hope to support optionally emitting diagnostics for cases like that
(and emitting runtime checks) in the future.

Release notes will appear shortly. :)

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


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

Add a visitor for lambda expressions to RecordExprEvaluator in ExprConstant.cpp that creates an empty APValue of Struct type to represent the closure object. Additionally, add a LambdaExpr visitor to the TemporaryExprEvaluator that forwards constant evaluation of immediately-called-lambda-expressions to the one in RecordExprEvaluator through VisitConstructExpr.

This patch supports:
constexpr auto ID = [] (auto a) { return a; };
static_assert(ID(3.14) == 3.14);
static_assert([](auto a) { return a + 1; }(10) == 11);

Lambda captures are still not supported for constexpr lambdas.



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

This implements something like the current direction of DR1581: we use a narrow
syntactic check to determine the set of places where a constant expression
could be evaluated, and only instantiate a constexpr function or variable if
it's referenced in one of those contexts, or is odr-used.

It's not yet clear whether this is the right set of syntactic locations; we
currently consider all contexts within templates that would result in odr-uses
after instantiation, and contexts within list-initialization (narrowing
conversions take another victim...), as requiring instantiation. We could in
principle restrict the former cases more (only const integral / reference
variable initializers, and contexts in which a constant expression is required,
perhaps). However, this is sufficient to allow us to accept libstdc++ code,
which relies on GCC's behavior (which appears to be somewhat similar to this
approach).


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

dependent context and can't be used in a constant expression.

Per C++ [temp.inst]p2, "the instantiation of a static data member does not
occur unless the static data member is used in a way that requires the
definition to exist".

This doesn't /quite/ match that, as we still instantiate static data members
that are usable in constant expressions even if the use doesn't require a
definition. A followup patch will fix that for both variables and functions.


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

Most code paths would already bail out in this case, but certain paths,
particularly overload resolution and typo correction, would not. Carrying on
with an invalid declaration could in some cases result in crashes due to
downstream code relying on declaration invariants that are not necessarily
met for invalid declarations, and in other cases just resulted in undesirable
follow-on diagnostics.


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

Summary: Fixed warnings in commit: https://reviews.llvm.org/rL290171

Reviewers: djasper, Anastasia

Subscribers: yaxunl, cfe-commits, bader

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

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

This reverts commit r290171. It triggers a bunch of warnings, because
the new enumerator isn't handled in all switches. We want a warning-free
build.

Replied on the commit with more details.

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

Summary: Enabling the compression of CLK_NULL_QUEUE to variable of type queue_t.

Reviewers: Anastasia

Subscribers: cfe-commits, yaxunl, bader

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

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

Fixed undefined behavior due to cast integer to bool in initializer list.


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

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

Added a map to associate types and declarations with extensions.

Refactored existing diagnostic for disabled types associated with extensions and extended it to declarations for generic situation.

Fixed some bugs for types associated with extensions.

Allow users to use pragma to declare types and functions for supported extensions, e.g.

#pragma OPENCL EXTENSION the_new_extension_name : begin
// declare types and functions associated with the extension here
#pragma OPENCL EXTENSION the_new_extension_name : end

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


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

At least the plugin used by the LibreOffice build
(<https://wiki.documentfoundation.org/Development/Clang_plugins>) indirectly
uses those members (through inline functions in LLVM/Clang include files in turn
using them), but they are not exported by utils/extract_symbols.py on Windows,
and accessing data across DLL/EXE boundaries on Windows is generally
problematic.

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

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

Improve handling of floating point literals in OpenCL to only use double precision if the target supports fp64.

This change makes sure single-precision floating point types are used if the 
cl_fp64 extension is not supported by the target.

Also removed the check to see whether the OpenCL version is >= 1.2, as this has
been incorporated into the extension setting code.

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



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

latter case, a temporary array object is materialized, and can be
lifetime-extended by binding a reference to the member access. Likewise, in an
array-to-pointer decay, an rvalue array is materialized before being converted
into a pointer.

This caused IR generation to stop treating file-scope array compound literals
as having static storage duration in some cases in C++; that has been rectified
by modeling such a compound literal as an lvalue. This also improves clang's
compatibility with GCC for those cases.


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

temporary produces an xvalue, not a prvalue. Support this by materializing the
temporary prior to performing the member access.


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

In passing, add a warning group for "ignored qualifier in inline assembly" warnings.


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

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

Summary:
We don't need a side table in ASTContext to hold CXXDefaultArgExprs. The
important part of building the CXXDefaultArgExprs was to ODR use the
default argument expressions, not to make AST nodes. Refactor the code
to only check the default argument, and remove the side table in
ASTContext which wasn't being serialized.

Fixes PR31121

Reviewers: thakis, rsmith, majnemer

Subscribers: cfe-commits

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

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

with __unknown_anytype return type.

When the following code is compiled, Sema infers that the type of
__unknown_anytype is double:

extern __unknown_anytype func();
double *d = (double*)&func();

This triggers an assert in CodeGenFunction::EmitCallExprLValue because
it doesn't expect to see a call to a function with a non-reference
scalar return type.

This commit prevents the assert by making VisitUnaryAddrOf error out if
the address-of operator is applied to a call to a function with
__unknown_anytype return type.

rdar://problem/20287610

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


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

Revert "Improve handling of floating point literals in OpenCL to only use double precision if the target supports fp64."

This reverts commit r286815, as it broke all ARM and AArch64 bots.

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

Improve handling of floating point literals in OpenCL to only use double precision if the target supports fp64.

This change makes sure single-precision floating point types are used if the 
cl_fp64 extension is not supported by the target.

Also removed the check to see whether the OpenCL version is >= 1.2, as this has
been incorporated into the extension setting code.

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



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@286815 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 assignment to NextIsDereference is either followed by (1) another,
unrelated assignment to NextIsDereference or by (2) an early loop exit.

Found by clang's static analyzer: http://llvm.org/reports/scan-build

(While we're at it fix a typo.)

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

the body of a function for the purposes of computing its storage
duration and deciding whether its initializer must be constant.

There are a number of problems in our current treatment of compound
literals.  C specifies that a compound literal yields an l-value
referring to an object with either static or automatic storage
duration, depending on where it was written; in the latter case,
the literal object has a lifetime tied to the enclosing scope (much
like an ObjC block), not the enclosing full-expression.  To get these
semantics fully correct in our current design, we would need to
collect compound literals on the ExprWithCleanups, just like we do
with ObjC blocks; we would probably also want to identify literals
like we do with materialized temporaries.  But it gets stranger;
GCC adds compound literals to C++ as an extension, but makes them
r-values, which are generally assumed to have temporary storage
duration.  Ignoring destructor ordering, the difference only matters
if the object's address escapes the full-expression, which for an
r-value can only happen with reference binding (which extends
temporaries) or array-to-pointer decay (which does not).  GCC then
attempts to lock down on array-to-pointer decay in ad hoc ways.
Arguably a far superior language solution for C++ (and perhaps even
array r-values in C, which can occur in other ways) would be to
propagate lifetime extension through array-to-pointer decay, so
that initializing a pointer object to a decayed r-value array
extends the lifetime of the complete object containing the array.
But this would be a major change in semantics which arguably ought
to be blessed by the committee(s).

Anyway, I'm not fixing any of that in this patch; I did try, but
it got out of hand.

Fixes rdar://28949016.

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

This is a misspelling of the intended !(x & A) negated bit test that happens in
practice every now and then.

I ran this on Chromium and all its dependencies, and it fired 0 times -- no
false or true positives, but it would've caught a bug in an in-progress change
that had to be caught by a Visual Studio warning instead.

https://reviews.llvm.org/D26035


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

The problem with the original commit was that some of Apple's headers depended
on an incorrect behaviour, this commit adds a temporary workaround until those
headers are fixed.

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

by blocks.

Add a new warning "-Wblock-capture-autoreleasing". The warning warns
about implicitly autoreleasing out-parameters captured by blocks which
can introduce use-after-free bugs that are hard to debug.

rdar://problem/15377548

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


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

This has two significant effects:

1) Direct relational comparisons between null pointer constants (0 and nullopt)
   and pointers are now ill-formed. This was always the case for C, and it
   appears that C++ only ever permitted by accident. For instance, cases like
     nullptr < &a
   are now rejected.

2) Comparisons and conditional operators between differently-cv-qualified
   pointer types now work, and produce a composite type that both source
   pointer types can convert to (when possible). For instance, comparison
   between 'int **' and 'const int **' is now valid, and uses an intermediate
   type of 'const int *const *'.

Clang previously supported #2 as an extension.

We do not accept the cases in #1 as an extension. I've tested a fair amount of
code to check that this doesn't break it, but if it turns out that someone is
relying on this, we can easily add it back as an extension.

This is a re-commit of r284800.


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

This reverts commit r284800, as it failed all ARM/AArch64 bots.

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

This has two significant effects:

1) Direct relational comparisons between null pointer constants (0 and nullopt)
   and pointers are now ill-formed. This was always the case for C, and it
   appears that C++ only ever permitted by accident. For instance, cases like
     nullptr < &a
   are now rejected.

2) Comparisons and conditional operators between differently-cv-qualified
   pointer types now work, and produce a composite type that both source
   pointer types can convert to (when possible). For instance, comparison
   between 'int **' and 'const int **' is now valid, and uses an intermediate
   type of 'const int *const *'.

Clang previously supported #2 as an extension.

We do not accept the cases in #1 as an extension. I've tested a fair amount of
code to check that this doesn't break it, but if it turns out that someone is
relying on this, we can easily add it back as an extension.


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

Gcc prints error if elements of left and right parts of a shift have different
sizes. This patch is provided the GCC compatibility.

Patch by Vladimir Yakovlev.

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


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

not instantiate exception specifications of functions if they were only used in
unevaluated contexts (other than 'noexcept' expressions).

In C++17 onwards, this becomes essential since the exception specification is
now part of the function's type.

Note that this means that constructs like the following no longer work:

  struct A {
    static T f() noexcept(...);
    decltype(f()) *p;
  };

... because the decltype expression now needs the exception specification of
'f', which has not yet been parsed.


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

This has a bug in it, pointed out by Bob Wilson!

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

implements the bulk of the change (modifying the type system to include
exception specifications), but not all the details just yet.


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

This commit combines a couple of redundant functions that do availability
attribute context checking into a more correct/simpler one.

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

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

argument, in order to correctly instantiate the initializer.


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

Summary:
Move CheckCUDACall from ActOnCallExpr and BuildDeclRefExpr to
DiagnoseUseOfDecl.  This lets us catch some edge cases we were missing,
specifically around class operators.

This necessitates a few other changes:

 - Avoid emitting duplicate deferred diags in CheckCUDACall.

   Previously we'd carefully placed our call to CheckCUDACall such that
   it would only ever run once for a particular callsite.  But now this
   isn't the case.

 - Emit deferred diagnostics from a template
   specialization/instantiation's primary template, in addition to from
   the specialization/instantiation itself.  DiagnoseUseOfDecl ends up
   putting the deferred diagnostics on the template, rather than the
   specialization, so we need to check both.

Reviewers: rsmith

Subscribers: cfe-commits, tra

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

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