Diagnose the case when a dependent template name instantiates to an
injected-class-name outside a nested-name-specifier.


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

Under this defect resolution, the injected-class-name of a class or class
template cannot be used except in very limited circumstances (when declaring a
constructor, in a nested-name-specifier, in a base-specifier, or in an
elaborated-type-specifier). This is apparently done to make parsing easier, but
it's a pain for us since we don't know whether a template-id using the
injected-class-name is valid at the point when we annotate it (we don't yet
know whether the template-id will become part of an elaborated-type-specifier).

As a tentative resolution to a perceived language defect, mem-initializer-ids
are added to the list of exceptions here (they generally follow the same rules
as base-specifiers).

When the reference to the injected-class-name uses the 'typename' or 'template'
keywords, we permit it to be used to name a type or template as an extension;
other compilers also accept some cases in this area. There are also a couple of
corner cases with dependent template names that we do not yet diagnose, but
which will also get this treatment.


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

This rule permits the injected-class-name of a class template to be used as
both a template type argument and a template template argument, with no extra
syntax required to disambiguate.


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

Diasllow a declaration using the 'auto' type specifier from using two different
meanings of it at once, or from declaring multiple functions with deduced
return types or introducing multiple trailing return types.

The standard does not technically disallow the multiple trailing return types
case if all the declarators declare variables (such as function pointers with
trailing return types), but we disallow that too, following the clear intent.


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

 * Update version number in DR tests from 4.0 to 4
 * Teach make_cxx_dr_status script about version numbers that don't contain a
   period.
 * Update cxx_status.html and cxx_dr_status.html to list Clang 4 features as
   "Clang 4" rather than "SVN"

Clang 4 features are still listed in yellow rather than green until release.


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

Updated index and UsersManual with OpenCL description.

Review: https://reviews.llvm.org/D28080 



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

Check for implicit conversion sequences for non-dependent function
template parameters between deduction and substitution. The idea is to accept
as many cases as possible, on the basis that substitution failure outside the
immediate context is much more common during substitution than during implicit
conversion sequence formation.

This re-commits r290808, reverted in r290811 and r291412, with a couple of
fixes for handling of explicitly-specified non-trailing template argument
packs.


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

This issue clarifies how deduction proceeds past a non-trailing function
parameter pack. Essentially, the pack itself is skipped and consumes no
arguments (except for those implied by an explicitly-specified template
arguments), and nothing is deduced from it. As a small fix to the standard's
rule, we do not allow subsequent deduction to change the length of the function
parameter pack (by preventing extension of the explicitly-specified pack if
present, and otherwise deducing all contained packs to empty packs).


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

The test-suite bots are still failing even after r291410's fix.


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

Check for implicit conversion sequences for non-dependent function
template parameters between deduction and substitution. The idea is to accept
as many cases as possible, on the basis that substitution failure outside the
immediate context is much more common during substitution than during implicit
conversion sequence formation.

This re-commits r290808, reverted in r290811, with a fix for handling of
explicitly-specified template argument packs.


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

Revert "DR1391: Check for implicit conversion sequences for non-dependent function template parameters between deduction and substitution. The idea is to accept as many cases as possible, on the basis that substitution failure outside the immediate context is much more common during substitution than during implicit conversion sequence formation."

This reverts commit r290808, as it broken all ARM and AArch64 test-suite
test: MultiSource/UnitTests/C++11/frame_layout

Also, please, next time, try to write a commit message in according to
our guidelines:

http://llvm.org/docs/DeveloperPolicy.html#commit-messages

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

template parameters between deduction and substitution. The idea is to accept
as many cases as possible, on the basis that substitution failure outside
the immediate context is much more common during substitution than during
implicit conversion sequence formation.

This does not implement the partial ordering portion of DR1391, which so
far appears to be misguided.


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

to be specified for a template template parameter whenever the parameter is at
least as specialized as the argument (when there's an obvious and correct
mapping from uses of the parameter to uses of the argument). For example, a
template with more parameters can be passed to a template template parameter
with fewer, if those trailing parameters have default arguments.

This is disabled by default, despite being a DR resolution, as it's fairly
broken in its current state: there are no partial ordering rules to cope with
template template parameters that have different parameter lists, meaning that
code that attempts to decompose template-ids based on arity can hit unavoidable
ambiguity issues.

The diagnostics produced on a non-matching argument are also pretty bad right
now, but I aim to improve them in a subsequent commit.


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

to make reference to template parameters. This is only a partial
implementation; we retain the restriction that the argument must not be
type-dependent, since it's unclear how that would work given the existence of
other language rules requiring an exact type match in this context, even for
type-dependent cases (a question has been raised on the core reflector).


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

specialized than the primary template. (Put another way, if we imagine there
were a partial specialization matching the primary template, we should never
select it if some other partial specialization also matches.)


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

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

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

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

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

We continue to support dynamic exception specifications in C++1z as an
extension, but produce an error-by-default warning when we encounter one. This
allows users to opt back into the feature with a warning flag, and implicitly
opts system headers back into the feature should they happen to use it.

There is one semantic change implied by P0003R5 but not implemented here:
violating a throw() exception specification should now call std::terminate
directly instead of calling std::unexpected(), but since P0003R5 also removes
std::unexpected() and std::set_unexpected, and the default unexpected handler
calls std::terminate(), a conforming C++1z program cannot tell that we are
still calling it. The upside of this strategy is perfect backwards
compatibility; the downside is that we don't get the more efficient 'noexcept'
codegen for 'throw()'.


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

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

P0012R1: add Itanium ABI support for throwing non-noexcept function pointers and catching as noexcept.


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

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

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

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

lambda-expression does not have a move-assignment operator.


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

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

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

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

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

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

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

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

on cxx-abi-dev (thread starting 2016-10-11). This is currently hidden behind a
cc1-only -m flag, pending discussion of how best to deal with language changes
that require use of new symbols from the ABI library.


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

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

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