------------------------------------------------------------------------
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

This flag serves no purpose other than to prevent us walking through a type to
check whether it contains an 'auto' specifier; this duplication of information
is error-prone, does not appear to provide any performance benefit, and will
become less practical once we support C++1z deduced class template types and
eventually constrained types from the Concepts TS.

No functionality change intended.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291737 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

the requested cv-qualifiers after construction. This usually doesn't matter,
but it does matter within a ?: operator.


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

This change introduces UsingPackDecl as a marker for the set of UsingDecls
produced by pack expansion of a single (unresolved) using declaration. This is
not strictly necessary (we just need to be able to map from the original using
declaration to its expansions somehow), but it's useful to maintain the
invariant that each declaration reference instantiates to refer to one
declaration.

This is a re-commit of r290080 (reverted in r290092) with a fix for a
use-after-lifetime bug.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290203 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

This reverts commit r290080 as it leads to many Clang crashes, e.g.:
http://lab.llvm.org:8011/builders/clang-cmake-aarch64-quick/builds/1814

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

This change introduces UsingPackDecl as a marker for the set of UsingDecls
produced by pack expansion of a single (unresolved) using declaration. This is
not strictly necessary (we just need to be able to map from the original using
declaration to its expansions somehow), but it's useful to maintain the
invariant that each declaration reference instantiates to refer to one
declaration.


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

constructs that can do so into the initialization code. This fixes a number
of different cases in which we used to fail to check for abstract types.

Thanks to Tim Shen for inspiring the weird code that uncovered this!


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

Although not specifically mentioned in the documentation, MSVC accepts
__uuidof(…) and declspec(uuid("…")) attributes on enumeration types in
addition to structs/classes. This is meaningful, as such types *do* have
associated UUIDs in ActiveX typelibs, and such attributes are included
by default in the wrappers generated by their #import construct, so they
are not particularly unusual.

clang currently rejects the declspec with a –Wignored-attributes
warning, and errors on __uuidof() with “cannot call operator __uuidof on
a type with no GUID” (because it rejected the uuid attribute, and
therefore finds no value). This is causing problems for us while trying
to use clang-tidy on a codebase that makes heavy use of ActiveX.

I believe I have found the relevant places to add this functionality,
this patch adds this case to clang’s implementation of these MS
extensions.  patch is against r285994 (or actually the git mirror
80464680).

Both include an update to test/Parser/MicrosoftExtensions.cpp to
exercise the new functionality.

This is my first time contributing to LLVM, so if I’ve missed anything
else needed to prepare this for review just let me know!

__uuidof: https://msdn.microsoft.com/en-us/library/zaah6a61.aspx
declspec(uuid("…")): https://msdn.microsoft.com/en-us/library/3b6wkewa.aspx
 #import: https://msdn.microsoft.com/en-us/library/8etzzkb6.aspx

Reviewers: aaron.ballman, majnemer, rnk

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

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

mirror the description in the standard. Per DR1295, this means that binding a
const / rvalue reference to a bit-field no longer "binds directly", and per
P0135R1, this means that we materialize a temporary in reference binding
after adjusting cv-qualifiers and before performing a derived-to-base cast.

In C++11 onwards, this should have fixed the last case where we would
materialize a temporary of the wrong type (with a subobject adjustment inside
the MaterializeTemporaryExpr instead of outside), but we still have to deal
with that possibility in C++98, unless we want to start using xvalues to
represent materialized temporaries there too.


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

When an object of class type is initialized from a prvalue of the same type
(ignoring cv qualifications), use the prvalue to initialize the object directly
instead of inserting a redundant elidable call to a copy constructor.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@288866 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

arguments from a declaration; despite what the standard says, this form of
deduction should not be considering exception specifications.


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

Since r274049, for an inheriting constructor declaration, the name of the using
declaration (and using shadow declaration comes from the using declaration) is
the name of a derived class, not the base class (line 8225-8232 of
lib/Sema/SemaDeclCXX.cpp in https://reviews.llvm.org/rL274049). Because of
this, name-based lookup performed inside Sema::LookupConstructors returns not
only CXXConstructorDecls but also Using(Shadow)Decls, which results assertion
failure reported in PR29087.

Patch by Taewook Oh, thanks!

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@287999 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

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

If initializer contains parentheses around braced list where it is not allowed,
as in construct int({0}), clang issued message like `functional-style cast
from 'void' to 'int' is not allowed`, which does not help much. Both gcc and
msvc issue message `list-initializer for non-class type must not be
parenthesized`, which is more descriptive. This change implements similar
message for clang.

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


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@286721 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

mismatched dynamic exception specifications in expressions from an error to a
warning, since this is no longer ill-formed in C++1z.

Allow reference binding of a reference-to-non-noexcept function to a noexcept
function lvalue. As defect resolutions, also allow a conditional between
noexcept and non-noexcept function lvalues to produce a non-noexcept function
lvalue (rather than decaying to a function pointer), and allow function
template argument deduction to deduce a reference to non-noexcept function when
binding to a noexcept function type.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@284905 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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@284879 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

Original commit message:

[c++1z] Teach composite pointer type computation how to compute the composite
pointer type of two function pointers with different noexcept specifications.
While I'm here, also teach it how to merge dynamic exception specifications.


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

It caused PR30749.

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

pointer type of two function pointers with different noexcept specifications.
While I'm here, also teach it how to merge dynamic exception specifications.


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

that a member is default-initializable even if it's initialized by a default
member initializer.


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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@284685 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

Summary:
Together these let you easily create diagnostics that

 - are never emitted for host code
 - are always emitted for __device__ and __global__ functions, and
 - are emitted for __host__ __device__ functions iff these functions are
   codegen'ed.

At the moment there are only three diagnostics that need this treatment,
but I have more to add, and it's not sustainable to write code for emitting
every such diagnostic twice, and from a special wrapper in SemaCUDA.cpp.

While we're at it, don't emit the function name in
err_cuda_device_exceptions: It's not necessary to print it, and making
this work in the new framework in the face of a null value for
dyn_cast<FunctionDecl>(CurContext) isn't worth the effort.

Reviewers: rnk

Subscribers: cfe-commits, tra

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

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

match other CUDA preference orders, per discussion with jlebar. We now model
this in an attempt to match overload resolution as closely as possible:

- First, we throw out all non-callable (due to CUDA host/device mismatch)
  operator delete functions.
- Then we apply sizedness / alignedness preferences based on whether the type
  is overaligned and whether the deallocation function is a member.
- Finally, we use the CUDA callability preference as a tiebreaker.


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

past-the-end iterator.

Original commit message:

P0035R4: Semantic analysis and code generation for C++17 overaligned
allocation.


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

This reverts commit r283722. Breaks:
  Clang.SemaCUDA.device-var-init.cu
  Clang.CodeGenCUDA.device-var-init.cu

http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-expensive/884/

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

allocation.


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

CheckSingleAssignmentConstraints. These no longer produce ExprError() when they
have not emitted an error, and reliably inform the caller when they *have*
emitted an error.

This fixes some serious issues where we would fail to emit any diagnostic for
invalid code and then attempt to emit code for an invalid AST, and conversely
some issues where we would emit two diagnostics for the same problem.


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

new expression, distinguish between the case of a constant and non-constant
initializer. In the former case, if the bound is erroneous (too many
initializer elements, bound is negative, or allocated size overflows), reject,
and take the bound into account when determining whether we need to
default-construct any elements. In the remanining cases, move the logic to
check for default-constructibility of trailing elements into the initialization
code rather than inventing a bogus array bound, to cope with cases where the
number of initialized elements is not the same as the number of initializer
list elements (this can happen due to string literal initialization or brace
elision).

This also fixes rejects-valid and crash-on-valid errors when initializing a
new'd array of character type from a braced string literal.


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

assume that ::operator new provides no more alignment than is necessary for any
primitive type, except when we're on a GNU OS, where glibc's malloc guarantees
to provide 64-bit alignment on 32-bit systems and 128-bit alignment on 64-bit
systems. This can be controlled by the command-line -fnew-alignment flag.


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