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

Summary: This patch implements http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#2094 which reverts Core 496.

Reviewers: rsmith

Reviewed By: rsmith

Subscribers: cfe-commits

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

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

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

Summary:
3.4.6 [basic.lookup.udir] paragraph 1:
In a using-directive or namespace-alias-definition, during the lookup for a namespace-name or for a name in a nested-name-specifier, only namespace names are considered.

Reviewers: rsmith, aaron.ballman

Subscribers: cfe-commits

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

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

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

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

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 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@289258 91177308-0d34-0410-b5e6-96231b3b80d8

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

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

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

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

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

explicit specialization to a warning for C++98 mode (this is a defect report
resolution, so per our informal policy it should apply in C++98), and turn
the warning on by default for C++11 and later. In all cases where it fires, the
right thing to do is to remove the pointless explicit instantiation.


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

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

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

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

instantiate to match a friend class declaration. It's still pretty dumb,
though.


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

C++11 requires const objects to have a user-provided constructor, even for
classes without any fields. DR 253 relaxes this to say "If the implicit default
constructor initializes all subobjects, no initializer should be required."

clang is currently the only compiler that implements this C++11 rule, and e.g.
libstdc++ relies on something like DR 253 to compile in newer versions.  This
change  makes it possible to build code that says `const vector<int> v;' again
when using libstdc++5.2 and _GLIBCXX_DEBUG
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60284).

Fixes PR23381.

http://reviews.llvm.org/D16552


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

Created by:
cd www
curl -O http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_index.html
./make_cxx_dr_status


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

We implemented this DR back in r258768 but forgot to mark it as
implemented.

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

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

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

DR407, the C++ standard doesn't really say how this should work. Here's what we
do (which is consistent with DR407 as far as I can tell):

 * When performing name lookup for an elaborated-type-specifier, a tag
   declaration hides a typedef declaration that names the same type.
 * When performing any other kind of lookup, a typedef declaration hides
   a tag declaration that names the same type.

In any other case where lookup finds both a typedef and a tag (that is, when
they name different types), the lookup will be ambiguous. If lookup finds a
tag and a typedef that name the same type, and finds anything else, the lookup
will always be ambiguous (even if the other entity would hide the tag, it does
not also hide the typedef).


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