Commit Graph

1876 Commits

Author SHA1 Message Date
Richard Smith cbe079321e [c++1z] Add some more tests for class template argument deduction, add
feature-test macro, and mark feature as done on status page.

llvm-svn: 295011
2017-02-14 00:55:25 +00:00
Richard Smith 3291877656 [c++1z] Synthesize implicit deduction guides from constructors on demand. Rank
such guides below explicit ones, and ensure that references to the class's
template parameters are not treated as forwarding references.

We make a few tweaks to the wording in the current standard:
1) The constructor parameter list is copied faithfully to the deduction guide,
   without losing default arguments or a varargs ellipsis (which the standard
   wording loses by omission).
2) If the class template declares no constructors, we add a T() -> T<...> guide
   (which will only ever work if T has default arguments for all non-pack
   template parameters).
3) If the class template declares nothing that looks like a copy or move
   constructor, we add a T(T<...>) -> T<...> guide.
#2 and #3 follow from the "pretend we had a class type with these constructors"
philosophy for deduction guides.

llvm-svn: 295007
2017-02-14 00:25:28 +00:00
Richard Smith bfbff07e73 [c++1z] Diagnose attempts to use variables with deduced class template
specialization types from within their own initializers.

llvm-svn: 294796
2017-02-10 22:35:37 +00:00
Richard Smith d69f4f5b05 [c++1z] Require an initializer for deduced class template specialization types.
It's actually meaningful and useful to allow such variables to have no
initializer, but we are strictly following the standard here until the C++
committee reaches consensus on allowing this.

llvm-svn: 294785
2017-02-10 21:40:29 +00:00
Richard Smith 278890f85b [c++1z] Enforce restriction that deduction guide is declared in the same scope as its template.
llvm-svn: 294778
2017-02-10 20:39:58 +00:00
Richard Smith 3817e4a40c [c++1z] Disallow deduction guides with deduced types that don't syntactically match the template being deduced.
llvm-svn: 294773
2017-02-10 19:49:50 +00:00
Richard Smith a2c581f42f [c++1z] In class template argument deduction, all declarators must deduce the same type (just like with auto deduction).
llvm-svn: 294700
2017-02-10 03:27:13 +00:00
Hubert Tong 5a8ec4e287 [Concepts] Class template associated constraints
Summary:
This adds associated constraints as a property of class templates.
An error is produced if redeclarations are not similarly constrained.

Reviewers: rsmith, faisalv, aaron.ballman

Reviewed By: rsmith

Subscribers: cfe-commits, nwilson

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

llvm-svn: 294697
2017-02-10 02:46:19 +00:00
Richard Smith afe4aa8b2c [c++1z] P0512R0: support for 'explicit' specifier on deduction-guides.
llvm-svn: 294693
2017-02-10 02:19:05 +00:00
Richard Smith 19a311a483 Disallow explicit instantiation and explicit specialization for deduction guides.
llvm-svn: 294641
2017-02-09 22:47:51 +00:00
Richard Smith 60437620db [c++1z] P0091R3: Basic support for deducing class template arguments via deduction-guides.
llvm-svn: 294613
2017-02-09 19:17:44 +00:00
Saleem Abdulrasool a6ae060db4 Sema: add warning for c++ member variable shadowing
Add a warning for shadowed variables across records.  Referencing a
shadow'ed variable may not give the desired variable.  Add an optional
warning for the shadowing.

Patch by James Sun!

llvm-svn: 294401
2017-02-08 03:30:13 +00:00
Richard Smith c88aa3f3a6 Diagnose an attempt to give a deduction-guide a function body.
llvm-svn: 294397
2017-02-08 01:27:29 +00:00
Richard Smith 8f8697f3e1 Fix constructor declarator detection for the case when the name is followed by
an attribute-specifier-seq. (Also fixes the same problem for deduction-guides.)

llvm-svn: 294396
2017-02-08 01:16:55 +00:00
Richard Smith f283fdcd50 P0091R3: Improved syntactic checking of deduction-guides.
llvm-svn: 294395
2017-02-08 00:35:25 +00:00
Richard Smith 3584515018 P0091R3: Implement basic parsing support for C++17 deduction-guides.
We model deduction-guides as functions with a new kind of name that identifies
the template whose deduction they guide; the bulk of this patch is adding the
new name kind. This gives us a clean way to attach an extensible list of guides
to a class template in a way that doesn't require any special handling in AST
files etc (and we're going to need these functions we come to performing
deduction).

llvm-svn: 294266
2017-02-07 01:37:30 +00:00
Richard Smith 3411fbff0b Repoint 'missing typename' diagnostic to the location where 'typename' should be added.
llvm-svn: 293817
2017-02-01 21:41:18 +00:00
Richard Smith 62559bd7ce Fix hole in our enforcement of rule requiring 'typename' prior to a dependent
name. If the dependent name happened to end in a template-id (X<T>::Y<U>), we
would fail to notice that the 'typename' keyword is missing when resolving it
to a type.

It turns out that GCC has a similar bug. If this shows up in much real code, we
can easily downgrade this to an ExtWarn.

llvm-svn: 293815
2017-02-01 21:36:38 +00:00
Richard Smith 600b5261c4 PR0091R3: Implement parsing support for using templates as types.
This change adds a new type node, DeducedTemplateSpecializationType, to
represent a type template name that has been used as a type. This is modeled
around AutoType, and shares a common base class for representing a deduced
placeholder type.

We allow deduced class template types in a few more places than the standard
does: in conditions and for-range-declarators, and in new-type-ids. This is
consistent with GCC and with discussion on the core reflector. This patch
does not yet support deduced class template types being named in typename
specifiers.

llvm-svn: 293207
2017-01-26 20:40:47 +00:00
Alex Lorenz 56fb6fef50 [Sema] Improve the error diagnostic for dot destructor calls on pointer objects
This commit improves the mismatched destructor type error by detecting when the
destructor call has used a '.' instead of a '->' on a pointer to the destructed
type. The diagnostic now suggests to use '->' instead of '.', and adds a fixit
where appropriate.

rdar://28766702

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

llvm-svn: 292615
2017-01-20 15:38:58 +00:00
Richard Smith fd3dae024f Finish implementation of C++ DR1310 (http://wg21.link/cwg1310).
Diagnose the case when a dependent template name instantiates to an
injected-class-name outside a nested-name-specifier.

llvm-svn: 292545
2017-01-20 00:20:39 +00:00
Richard Smith 74f02347ca PR13403 (+duplicates): implement C++ DR1310 (http://wg21.link/cwg1310).
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.

llvm-svn: 292518
2017-01-19 21:00:13 +00:00
Richard Smith 11255ec765 PR9551: Implement DR1004 (http://wg21.link/cwg1004).
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.

llvm-svn: 292426
2017-01-18 19:19:22 +00:00
Richard Smith 0c062b408b Give more accurate descriptions of what kind of template we found in diagnostics.
We were previouly assuming that every type template was a class template, which
is not true any more.

llvm-svn: 291988
2017-01-14 02:19:59 +00:00
Richard Smith 836a3b416d PR31606: Generalize our tentative DR resolution for inheriting copy/move
constructors to better match the pre-P0136R1 behavior.

llvm-svn: 291955
2017-01-13 20:46:54 +00:00
Malcolm Parsons 87a036259b [Sema] Add warning for unused lambda captures
Summary:
Warn when a lambda explicitly captures something that is not used in its body.

The warning is part of -Wunused and can be enabled with -Wunused-lambda-capture.

Reviewers: rsmith, arphaman, jbcoe, aaron.ballman

Subscribers: Quuxplusone, arphaman, cfe-commits

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

llvm-svn: 291905
2017-01-13 15:01:06 +00:00
Richard Smith 8210ed5586 Implement DR1265 (wg21.link/cwg1265).
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.

llvm-svn: 291880
2017-01-13 02:22:01 +00:00
Richard Smith d7279bba20 Update C++ status pages for Clang 4 branch:
* 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.

llvm-svn: 291871
2017-01-13 00:57:54 +00:00
David L. Jones f55ce36c02 Allow constexpr construction of subobjects unconditionally, not just in C++14.
Summary:
Per https://wg21.link/CWG1677, the C++11 standard did not clarify that constant
initialization of an object allowed constexpr brace-or-equal initialization of
subobjects:

  struct foo_t { union { int i; volatile int j; } u; };

  __attribute__((__require_constant_initialization__))
  static const foo_t x = {{0}};

Because foo_t::u has a volatile member, the initializer for x fails. However,
there is really no good reason, because this:

  union foo_u { int i; volatile int j; };
  __attribute__((__require_constant_initialization__))
  static const foo_u x = {0};

does have a constant initializer.

(This was triggered by musl's pthread_mutex_t type when building under C++11.)

Reviewers: rsmith

Subscribers: EricWF, cfe-commits

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

llvm-svn: 291480
2017-01-09 21:38:07 +00:00
Richard Smith 6eedfe77c1 Implement C++ DR1391 (wg21.link/cwg1391)
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.

llvm-svn: 291427
2017-01-09 08:01:21 +00:00
Richard Smith de0d34a576 Implement DR1388 (wg21.link/cwg1388).
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).

llvm-svn: 291425
2017-01-09 07:14:40 +00:00
Richard Smith 7950d82ab5 Revert r291410 and r291411.
The test-suite bots are still failing even after r291410's fix.

llvm-svn: 291412
2017-01-09 01:18:18 +00:00
Richard Smith d22652122d Implement C++ DR1391 (wg21.link/cwg1391)
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.

llvm-svn: 291410
2017-01-09 00:43:47 +00:00
Richard Smith f9c59b7122 PR30305: Implement proposed DR resolution to prevent slicing via inherited constructor.
The rule we use is that a construction of a class type T from an argument of
type U cannot use an inherited constructor if U is the same as T or is derived
from T (or if the initialization would first convert it to such a type). This
(approximately) matches the rule in use by GCC, and matches the current proposed
DR resolution.

llvm-svn: 291403
2017-01-08 21:45:44 +00:00
Richard Smith d6a150829b PR23135: Don't instantiate constexpr functions referenced in unevaluated operands where possible.
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).

llvm-svn: 291318
2017-01-07 00:48:55 +00:00
Renato Golin dad96d6751 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

llvm-svn: 290811
2017-01-02 11:15:42 +00:00
Richard Smith efcfe86072 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 does not implement the partial ordering portion of DR1391, which so
far appears to be misguided.

llvm-svn: 290808
2017-01-02 02:42:17 +00:00
Richard Smith 57aae07b4a DR1315: a non-type template argument in a partial specialization is permitted
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).

llvm-svn: 290647
2016-12-28 02:37:25 +00:00
Richard Smith 0e617ecdd1 DR1495: A partial specialization is ill-formed if it is not (strictly) more
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.)

llvm-svn: 290593
2016-12-27 07:56:27 +00:00
Richard Smith 792c22dbd4 When producing a name of a partial specialization in a diagnostic, use the
template arguments as written rather than the canonical template arguments,
so we print more user-friendly names for template parameters.

llvm-svn: 290483
2016-12-24 04:09:05 +00:00
Richard Smith 593d6a168f When merging two deduced non-type template arguments for the same parameter,
fail the merge if the arguments have different types (except if one of them was
deduced from an array bound, in which case take the type from the other).

This is correct because (except in the array bound case) the type of the
template argument in each deduction must match the type of the parameter, so at
least one of the two deduced arguments must have a mismatched type.

This is necessary because we would otherwise lose the type information for the
discarded template argument in the merge, and fail to diagnose the mismatch.

In order to power this, we now properly retain the type of a deduced non-type
template argument deduced from a declaration, rather than giving it the type of
the template parameter; we'll convert it to the template parameter type when
checking the deduced arguments.

llvm-svn: 290399
2016-12-23 01:30:39 +00:00
Chandler Carruth fcd33149b4 Cleanup the handling of noinline function attributes, -fno-inline,
-fno-inline-functions, -O0, and optnone.

These were really, really tangled together:
- We used the noinline LLVM attribute for -fno-inline
  - But not for -fno-inline-functions (breaking LTO)
  - But we did use it for -finline-hint-functions (yay, LTO is happy!)
  - But we didn't for -O0 (LTO is sad yet again...)
- We had weird structuring of CodeGenOpts with both an inlining
  enumeration and a boolean. They interacted in weird ways and
  needlessly.
- A *lot* of set smashing went on with setting these, and then got worse
  when we considered optnone and other inlining-effecting attributes.
- A bunch of inline affecting attributes were managed in a completely
  different place from -fno-inline.
- Even with -fno-inline we failed to put the LLVM noinline attribute
  onto many generated function definitions because they didn't show up
  as AST-level functions.
- If you passed -O0 but -finline-functions we would run the normal
  inliner pass in LLVM despite it being in the O0 pipeline, which really
  doesn't make much sense.
- Lastly, we used things like '-fno-inline' to manipulate the pass
  pipeline which forced the pass pipeline to be much more
  parameterizable than it really needs to be. Instead we can *just* use
  the optimization level to select a pipeline and control the rest via
  attributes.

Sadly, this causes a bunch of churn in tests because we don't run the
optimizer in the tests and check the contents of attribute sets. It
would be awesome if attribute sets were a bit more FileCheck friendly,
but oh well.

I think this is a significant improvement and should remove the semantic
need to change what inliner pass we run in order to comply with the
requested inlining semantics by relying completely on attributes. It
also cleans up tho optnone and related handling a bit.

One unfortunate aspect of this is that for generating alwaysinline
routines like those in OpenMP we end up removing noinline and then
adding alwaysinline. I tried a bunch of other approaches, but because we
recompute function attributes from scratch and don't have a declaration
here I couldn't find anything substantially cleaner than this.

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

llvm-svn: 290398
2016-12-23 01:24:49 +00:00
Chandler Carruth 93786da2cb Make '-disable-llvm-optzns' an alias for '-disable-llvm-passes'.
Much to my surprise, '-disable-llvm-optzns' which I thought was the
magical flag I wanted to get at the raw LLVM IR coming out of Clang
deosn't do that. It still runs some passes over the IR. I don't want
that, I really want the *raw* IR coming out of Clang and I strongly
suspect everyone else using it is in the same camp.

There is actually a flag that does what I want that I didn't know about
called '-disable-llvm-passes'. I suspect many others don't know about it
either. It both does what I want and is much simpler.

This removes the confusing version and makes that spelling of the flag
an alias for '-disable-llvm-passes'. I've also moved everything in Clang
to use the 'passes' spelling as it seems both more accurate (*all* LLVM
passes are disabled, not just optimizations) and much easier to remember
and spell correctly.

This is part of simplifying how Clang drives LLVM to make it cleaner to
wire up to the new pass manager.

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

llvm-svn: 290392
2016-12-23 00:23:01 +00:00
Richard Smith 16d3150852 [c++1z] When initializing a const-qualified class type, don't forget to add on
the requested cv-qualifiers after construction. This usually doesn't matter,
but it does matter within a ?: operator.

llvm-svn: 290227
2016-12-21 01:31:56 +00:00
Richard Smith 543f1acadb Add test for DR692.
llvm-svn: 290166
2016-12-20 07:24:53 +00:00
Richard Smith 4eeaec46f7 Fix name hiding and redeclaration checking for dependent local
using-declarations.

llvm-svn: 290072
2016-12-18 22:01:46 +00:00
Richard Smith d8a9e37558 Fix some interactions between C++11 and C++14 features and using-declarations:
* a dependent non-type using-declaration within a function template can be
   valid, as it can refer to an enumerator, so don't reject it in the template
   definition
 * we can partially substitute into a dependent using-declaration if it appears
   within a (local class in a) generic lambda within a function template, which
   means an UnresolvedUsing*Decl doesn't necessarily instantiate to a UsingDecl.

llvm-svn: 290071
2016-12-18 21:39:37 +00:00
Richard Smith 81f5ade227 Move checks for creation of objects of abstract class type from the various
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!

llvm-svn: 289753
2016-12-15 02:28:18 +00:00
Richard Smith 378b8c8f01 [c++1z] P0217R3: Allow by-value structured binding of arrays.
llvm-svn: 289630
2016-12-14 03:22:16 +00:00
Richard Smith 30e304e2a6 Remove custom handling of array copies in lambda by-value array capture and
copy constructors of classes with array members, instead using
ArrayInitLoopExpr to represent the initialization loop.

This exposed a bug in the static analyzer where it was unable to differentiate
between zero-initialized and unknown array values, which has also been fixed
here.

llvm-svn: 289618
2016-12-14 00:03:17 +00:00
Reid Kleckner 1a4ab7e772 Improve error message when referencing a non-tag type with a tag
Other compilers accept invalid code here that we reject, and we need a
better error message to try to convince users that the code is really
incorrect. Consider:
  class Foo {
    typedef MyIterHelper<Foo> iterator;
    friend class iterator;
  };

Previously our wording was "elaborated type refers to a typedef".
"elaborated type" isn't widely known terminology, so the new diagnostic
says "typedef 'iterator' cannot be referenced with class specifier".

Reviewers: rsmith

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

llvm-svn: 289259
2016-12-09 19:47:58 +00:00
Richard Smith f0e87cf2c3 Add tests for a couple more DRs.
llvm-svn: 289258
2016-12-09 19:35:45 +00:00
Richard Smith b11b087a85 cxx_dr_status: update to latest issue list and add a couple more tests.
llvm-svn: 289255
2016-12-09 19:11:50 +00:00
Richard Smith b8c0f553ed DR1295 and cleanup for P0135R1: Make our initialization code more directly
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.

llvm-svn: 289250
2016-12-09 18:49:13 +00:00
Richard Smith 208732e954 [c++1z] P0490R0, NB comment GB 20: if std::tuple_size<T> is complete, use the
tuple-like interpretation of decomposition declaration even if there is no
::value member. We already did this, anticipating this resolution, just update
comments and tweak a testcase.

llvm-svn: 289021
2016-12-08 03:24:55 +00:00
Richard Smith 82da19ddb3 [c++1z] P0003R5: Removing dynamic exception specifications.
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()'.

llvm-svn: 289019
2016-12-08 02:49:07 +00:00
Richard Smith 122f88d481 [c++17] P0135R1: Guaranteed copy elision.
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.

llvm-svn: 288866
2016-12-06 23:52:28 +00:00
Richard Smith b3189a1802 DR1213: element access on an array xvalue or prvalue produces an xvalue. In the
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.

llvm-svn: 288654
2016-12-05 07:49:14 +00:00
Eric Fiselier 283d8d45db [Sema] Don't perform aggregate initialization for types with explicit constructors
Summary:
The C++17 rules for aggregate initialization changed to disallow types with explicit constructors [dcl.init.aggr]p1. This patch implements that new rule.


Reviewers: rsmith

Subscribers: cfe-commits

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

llvm-svn: 288565
2016-12-03 01:26:47 +00:00
Richard Smith 4baaa5ab52 DR616, and part of P0135R1: member access (or pointer-to-member access) on a
temporary produces an xvalue, not a prvalue. Support this by materializing the
temporary prior to performing the member access.

llvm-svn: 288563
2016-12-03 01:14:32 +00:00
Richard Smith ca18579766 PR23281: Fix implementation of DR1891 to implement the intent: that is, a
lambda-expression does not have a move-assignment operator.

llvm-svn: 287057
2016-11-16 00:03:24 +00:00
Eric Fiselier e4e9e281a1 [Sema] Allow static_cast<T&&>(e) to check explicit conversions for non-reference-related types.
Summary:
[expr.cast.static] states:
> 3. A glvalue of type “cv1 T1” can be cast to type “rvalue reference to cv2 T2” if “cv2 T2” is reference-compatible
> with “cv1 T1”. The result refers to the object or the specified base class subobject thereof. If T2 is
> an inaccessible or ambiguous base class of T1, a program that necessitates such a cast is
> ill-formed.
> 
> 4. Otherwise, an expression e can be explicitly converted to a type T using a static_cast of the form static_-
> cast<T>(e) if the declaration T t(e); is well-formed, for some invented temporary variable t. [...]

Currently when checking p3 Clang will diagnose `static_cast<T&&>(e)` as invalid if the argument is not reference compatible with `T`. However I believe the correct behavior is to also check p4 in those cases.  For example:

```
double y = 42;
static_cast<int&&>(y); // this should be OK.  'int&& t(y)' is well formed
```

Note that we still don't check p4 for non-reference-compatible types which are reference-related since  `T&& t(e);` should never be well formed in those cases.


Reviewers: rsmith

Subscribers: cfe-commits

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

llvm-svn: 285872
2016-11-03 02:13:17 +00:00
Alex Lorenz 560ae565e9 Add a note that points to the linkage specifier for the C++ linkage errors
This commit improves the "must have C++ linkage" error diagnostics that are
emitted for C++ declarations like templates and literal operators by adding an
additional note that points to the appropriate extern "C" linkage specifier.

rdar://19021120

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

llvm-svn: 285823
2016-11-02 15:46:34 +00:00
Richard Smith f3cec65d01 When diagnosing that a defaulted function is ill-formed because it would be
implicitly deleted and overrides a non-deleted function, explain why the
function is deleted. For PR30844.

llvm-svn: 285610
2016-10-31 18:18:29 +00:00
Richard Smith a99fa39c41 Fix handling of constructor inherited through multiple levels of virtual base class.
llvm-svn: 285446
2016-10-28 20:20:58 +00:00
Richard Smith fda59e5851 Implement name mangling proposal for exception specifications from cxx-abi-dev 2016-10-11.
This has the following ABI impact:

 1) Functions whose parameter or return types are non-throwing function pointer
    types have different manglings in c++1z mode from prior modes. This is
    necessary because c++1z permits overloading on the noexceptness of function
    pointer parameter types. A warning is issued for cases that will change
    manglings in c++1z mode.

 2) Functions whose parameter or return types contain instantiation-dependent
    exception specifications change manglings in all modes. This is necessary
    to support overloading on / SFINAE in these exception specifications, which
    a careful reading of the standard indicates has essentially always been
    permitted.

Note that, in order to be affected by these changes, the code in question must
specify an exception specification on a function pointer/reference type that is
written syntactically within the declaration of another function. Such
declarations are very rare, and I have so far been unable to find any code
that would be affected by this. (Note that such things will probably become
more common in C++17, since it's a lot easier to get a noexcept function type
as a function parameter / return type there.)

This change does not affect the set of symbols produced by a build of clang,
libc++, or libc++abi.

llvm-svn: 285150
2016-10-26 01:05:54 +00:00
Richard Smith 58b4ab845a Add another testcase missed from r284905.
llvm-svn: 284906
2016-10-22 01:32:45 +00:00
Richard Smith 1be59c5106 [c++1z] P0012R1: Implement a few remaining pieces: downgrade diagnostic for
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.

llvm-svn: 284905
2016-10-22 01:32:19 +00:00
Richard Smith 5e9746f520 DR583, DR1512: Implement a rewrite to C++'s 'composite pointer type' rules.
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.

llvm-svn: 284890
2016-10-21 22:00:42 +00:00
Renato Golin 41189656ed Revert "DR583, DR1512: Implement a rewrite to C++'s 'composite pointer type' rules."
This reverts commit r284800, as it failed all ARM/AArch64 bots.

llvm-svn: 284811
2016-10-21 08:03:49 +00:00
Richard Smith 0c1c53e3fa DR583, DR1512: Implement a rewrite to C++'s 'composite pointer type' rules.
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.

llvm-svn: 284800
2016-10-21 02:36:37 +00:00
Richard Smith eb7ef2e1ca Re-commit r284753, reverted in r284778, with a fix for PR30749.
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.

llvm-svn: 284785
2016-10-20 21:53:09 +00:00
Hans Wennborg 2b81f42a76 Revert r284753 "[c++1z] Teach composite pointer type computation how to compute the composite"
It caused PR30749.

llvm-svn: 284778
2016-10-20 20:54:32 +00:00
Richard Smith 9c37e66c31 [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.

llvm-svn: 284753
2016-10-20 17:57:33 +00:00
Richard Smith 84a0b6dba1 DR1330: instantiate exception-specifications when "needed". We previously did
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.

llvm-svn: 284549
2016-10-18 23:39:12 +00:00
NAKAMURA Takumi e04c253a94 clang/test/CXX/conv/conv.fctptr/p1.cpp: Appease for targeting i686-win32.
error: 'error' diagnostics seen but not expected:
    File clang\test\CXX\conv\conv.fctptr\p1.cpp Line 16: assigning to 'void (S::*)() __attribute__((thiscall)) noexcept' from incompatible type 'void (S::*)() __attribute__((thiscall))': different exception specifications

llvm-svn: 284352
2016-10-16 23:00:18 +00:00
Richard Smith 3c4f8d2e96 P0012R1: Make exception specifications be part of the type system. This
implements the bulk of the change (modifying the type system to include
exception specifications), but not all the details just yet.

llvm-svn: 284337
2016-10-16 17:54:23 +00:00
Richard Smith ebb006e875 Extend this test and make it a bit clearer which cases Clang is getting wrong.
llvm-svn: 284331
2016-10-16 06:23:29 +00:00
Richard Smith b2f0f05742 Re-commit r283722, reverted in r283750, with a fix for a CUDA-specific use of
past-the-end iterator.

Original commit message:

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

llvm-svn: 283789
2016-10-10 18:54:32 +00:00
Daniel Jasper e9abe64816 Revert "P0035R4: Semantic analysis and code generation for C++17 overaligned allocation."
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/

llvm-svn: 283750
2016-10-10 14:13:55 +00:00
Richard Smith 189e52fcdf P0035R4: Semantic analysis and code generation for C++17 overaligned
allocation.

llvm-svn: 283722
2016-10-10 06:42:31 +00:00
Richard Smith e15a370084 PR25890: Fix incoherent error handling in PerformImplicitConversion and
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.

llvm-svn: 283508
2016-10-06 23:12:58 +00:00
Richard Smith 360cb2570e Fix bogus "inline namespace cannot be reopened as non-inline" diagnostic to
just warn that the second declaration is missing the 'inline' keyword. This is
valid, and we shouldn't be suggesting otherwise.

llvm-svn: 282981
2016-09-30 23:16:08 +00:00
Richard Smith 591390284f P0035R4: add predefined __STDCPP_DEFAULT_NEW_ALIGNMENT__ macro. By default, we
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.

llvm-svn: 282974
2016-09-30 22:41:36 +00:00
Richard Smith 96269c59ea P0035R4: add std::align_val_t overloads of operator new/delete in C++17 mode.
llvm-svn: 282800
2016-09-29 22:49:46 +00:00
Ismail Pazarbasi 4a00774e59 Try contextually converting condition of constexpr if to Boolean value
Summary:
C++1z 6.4.1/p2:
 If the if statement is of the form if constexpr, the value of the
 condition shall be a contextually converted constant expression of type
 bool [...]
C++1z 5.20/p4:
 [...] A contextually converted constant expression of type bool is an
 expression, contextually converted to bool (Clause4), where the
 converted expression is a constant expression and the conversion
 sequence contains only the conversions above. [...]

Contextually converting result of an expression `e` to a Boolean value
requires `bool t(e)` to be well-formed.

An explicit conversion function is only considered as a user-defined
conversion for direct-initialization, which is essentially what
//contextually converted to bool// requires.

Also, fixes PR28470.

Reviewers: rsmith

Subscribers: cfe-commits

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

llvm-svn: 280838
2016-09-07 18:24:54 +00:00
Richard Smith 7c2bcc9eb0 Fix clang's handling of the copy performed in the second phase of class
copy-initialization. We previously got this wrong in a couple of ways:
 - we only looked for copy / move constructors and constructor templates for
   this copy, and thus would fail to copy in cases where doing so should use
   some other constructor (but see core issue 670),
 - we mishandled the special case for disabling user-defined conversions that
   blocks infinite recursion through repeated application of a copy constructor
   (applying it in slightly too many cases) -- though as far as I can tell,
   this does not ever actually affect the result of overload resolution, and
 - we misapplied the special-case rules for constructors taking a parameter
   whose type is a (reference to) the same class type by incorrectly assuming
   that only happens for copy/move constructors (it also happens for
   constructors instantiated from templates and those inherited from base
   classes).

These changes should only affect strange corner cases (for instance, where the
copy constructor exists but has a non-const-qualified parameter type), so for
the most part it only causes us to produce more 'candidate' notes, but see the
test changes for other cases whose behavior is affected.

llvm-svn: 280776
2016-09-07 02:14:33 +00:00
Richard Smith 53851923d5 Fix all tests under test/CXX (and test/Analysis) to pass if clang's default
C++ language standard is not C++98.

llvm-svn: 280309
2016-08-31 23:24:08 +00:00
Richard Smith e4caa48dbb DR259: Demote the pedantic error for an explicit instantiation after an
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.

llvm-svn: 280308
2016-08-31 23:23:25 +00:00
Richard Smith e3ea001ec8 Don't diagnoes a mismatch between implicit and explicit exception
specifications under -fno-exceptions, just as we don't diagnose other exception
specification mismatch errors.

llvm-svn: 280289
2016-08-31 20:38:32 +00:00
Richard Smith 0786d5b9e6 Fix mishandling of deletedness for assignment operators of classes with
indirect virtual bases. We don't need to be able to invoke such an assignment
operator from the derived class, and we shouldn't delete the derived assignment
op if we can't do so.

llvm-svn: 280288
2016-08-31 20:37:39 +00:00
Richard Smith dd5619feac PR28978: If we need overload resolution for the move constructor of an
anonymous union member of a class, we need overload resolution for the move
constructor of the class itself too; we can't rely on Sema to do the right
thing for us for anonymous union types.

llvm-svn: 278763
2016-08-16 00:13:47 +00:00
Benjamin Kramer df8bf140dd [C++1z] Fix crash when decomposing structs with anonymous members.
The diagnostic format was invalid.

llvm-svn: 278487
2016-08-12 09:19:34 +00:00
Richard Smith dca60b4958 P0217R3: Constant expression evaluation for decomposition declarations.
llvm-svn: 278447
2016-08-12 00:39:32 +00:00
Richard Smith 7873de0cf6 P0217R3: Perform semantic checks and initialization for the bindings in a
decomposition declaration for arrays, aggregate-like structs, tuple-like
types, and (as an extension) for complex and vector types.

llvm-svn: 278435
2016-08-11 22:25:46 +00:00
Richard Smith 3cbf3f1f59 Push alias-declarations and alias-template declarations into scope even if
they're redeclarations. This is necessary in order for name lookup to correctly
find the most recent declaration of the name (which affects default template
argument lookup and cross-module merging, among other things).

llvm-svn: 275612
2016-07-15 20:53:25 +00:00
Erik Pilkington f1bd000f71 [Sema] Fix a bug where pack expansion was not expanded in type alias
The problem is that the parameter pack in a function type type alias is not
reexpanded after being transformed. Also remove an incorrect comment in a
similar function. Fixes PR26017.

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

llvm-svn: 274566
2016-07-05 17:57:24 +00:00
Erik Pilkington fc235eb780 [Sema] Implement C++14's DR1579: Prefer returning by converting move constructor
Fixes PR28096.

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

llvm-svn: 274291
2016-06-30 23:09:13 +00:00
Richard Smith 80a4702d02 Mark inheriting constructors as deleted if the corresponding defaulted default
constructor would be; this is effectively required by P0136R1. This has the
effect of exposing the validity of the base class initialization steps to
SFINAE checks.

llvm-svn: 274088
2016-06-29 01:10:27 +00:00
Erik Pilkington 6a16ac0ed7 [Sema] Disallow ambigious base classes in template argument deduction
Fixes PR28195.

Differential revision: http://reviews.llvm.org/D21653

llvm-svn: 274077
2016-06-28 23:05:09 +00:00