summaryrefslogtreecommitdiffstats
path: root/clang/test/CXX
Commit message (Collapse)AuthorAgeFilesLines
...
* revert changes from r311851.Faisal Vali2017-08-271-14/+3
| | | | | | | | The right answers here (and how clang needs to be tweaked) require further analysis (ongoing cwg thread). sorry. llvm-svn: 311855
* Don't see through 'using member-declarations' when determining the relation ↵Faisal Vali2017-08-271-3/+14
| | | | | | | | | | | | | | | | | | | | | | | | | of any potential implicit object expression to the parent class of the member function containing the function call. Prior to this patch clang would not error here: template <class T> struct B; template <class T> struct A { void foo(); void foo2(); void test1() { B<T>::foo(); // OK, foo is declared in A<int> - matches type of 'this'. B<T>::foo2(); // This should be an error! // foo2 is found in B<int>, 'base unrelated' to 'this'. } }; template <class T> struct B : A<T> { using A<T>::foo2; }; llvm-svn: 311851
* [c++2a] Implement P0409R2 - Allow lambda capture [=,this] (by hamzasood)Faisal Vali2017-08-191-2/+2
| | | | | | | | | | This patch, by hamzasood, implements P0409R2, and allows [=, this] pre-C++2a as an extension (with appropriate warnings) for consistency. https://reviews.llvm.org/D36572 Thanks Hamza! llvm-svn: 311224
* Do not look through pack expansions when looking for unexpanded parameter packs.Richard Smith2017-08-151-0/+98
| | | | | | | Fixes a selection of rejects-valids when pack-expanding a lambda that itself contains a pack expansion. llvm-svn: 310972
* Replace remaining user-visible mentions of C++1z with C++17.Richard Smith2017-08-139-43/+43
| | | | llvm-svn: 310804
* PR33850: Update cxx_dr_status for Clang 5 branch.Richard Smith2017-08-112-2/+2
| | | | llvm-svn: 310692
* [modules ts] Basic for module linkage.Richard Smith2017-07-073-7/+106
| | | | | | | | | | In addition to the formal linkage rules, the Modules TS includes cases where internal-linkage symbols within a module interface unit can be referenced from outside the module via exported inline functions / templates. We give such declarations "module-internal linkage", which is formally internal linkage, but results in an externally-visible symbol. llvm-svn: 307434
* [modules ts] Do not emit strong function definitions from the module ↵Richard Smith2017-07-063-0/+90
| | | | | | interface unit in every user. llvm-svn: 307232
* Address comments that escaped D33333Erich Keane2017-07-051-2/+2
| | | | | | | | Patch By: Jen Yu Differential Revision:https://reviews.llvm.org/D34671 llvm-svn: 307172
* [modules ts] Improve merging of module-private declarations.Richard Smith2017-07-051-0/+33
| | | | | | | | | | These cases occur frequently for declarations in the global module (above the module-declaration) in a Modules TS module interface. When we merge a definition from another module into such a module-private definition, ensure that we transitively make everything lexically within that definition visible to that translation unit. llvm-svn: 307129
* [modules ts] Declarations from a module interface unit are only visible outsideRichard Smith2017-07-054-2/+64
| | | | | | the module if declared in an export block. llvm-svn: 307115
* Emit warning when throw exception in destruct or dealloc functions which has a Erich Keane2017-06-231-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (possible implicit) noexcept specifier Throwing in the destructor is not good (C++11 change try to not allow see below). But in reality, those codes are exist. C++11 [class.dtor]p3: A declaration of a destructor that does not have an exception-specification is implicitly considered to have the same exception specification as an implicit declaration. With this change, the application worked before may now run into runtime termination. My goal here is to emit a warning to provide only possible info to where the code may need to be changed. First there is no way, in compile time to identify the “throw” really throw out of the function. Things like the call which throw out… To keep this simple, when “throw” is seen, checking its enclosing function(only destructor and dealloc functions) with noexcept(true) specifier emit warning. Here is implementation detail: A new member function CheckCXXThrowInNonThrowingFunc is added for class Sema in Sema.h. It is used in the call to both BuildCXXThrow and TransformCXXThrowExpr. The function basic check if the enclosing function with non-throwing noexcept specifer, if so emit warning for it. The example of warning message like: k1.cpp:18:3: warning: ''~dependent_warn'' has a (possible implicit) non-throwing noexcept specifier. Throwing exception may cause termination. [-Wthrow-in-dtor] throw 1; ^ k1.cpp:43:30: note: in instantiation of member function 'dependent_warn<noexcept_fun>::~dependent_warn' requested here dependent_warn<noexcept_fun> f; // cause warning Differential Revision: https://reviews.llvm.org/D33333 llvm-svn: 306149
* Do not inherit default arguments for friend function in class template.Serge Pavlov2017-06-081-0/+33
| | | | | | | | | | | | | | | | | | | A function declared in a friend declaration may have declarations prior to the containing class definition. If such declaration defines default argument, the friend function declaration inherits them. This behavior causes problems if the class where the friend is declared is a template: during the class instantiation the friend function looks like if it had default arguments, so error is triggered. With this change friend functions declared in class templates do not inherit default arguments. Actual set of them will be defined at the point where the containing class is instantiated. This change fixes PR12724. Differential Revision: https://reviews.llvm.org/D30393 llvm-svn: 304965
* Improve diagnostics if friend function redefines file-level function.Serge Pavlov2017-06-081-0/+28
| | | | | | | | | | | | | | | | | | | | | | Clang makes check for function redefinition after it merged the new declaration with the existing one. As a result, it produces poor diagnostics in the case of a friend function defined inline, as in the code: ``` void func() {} class C { friend void func() {} }; ``` Error message in this case states that `inline declaration of 'func' follows non-inline definition`, which is misleading, as `func` does not have explicit `inline` specifier. With this changes compiler reports function redefinition if the new function is a friend defined inline and it does not have explicit `inline` specifier. Differential Revision: https://reviews.llvm.org/D26065 llvm-svn: 304964
* When determining the target function of an explicit instantiation, makeJohn McCall2017-06-071-0/+13
| | | | | | | | | | sure that non-template functions don't end up in the candidate set. Fixes PR14211. Patch by Don Hinton! llvm-svn: 304951
* [c++1z] Support deducing B in noexcept(B).Richard Smith2017-06-072-6/+16
| | | | | | | | This is not required by the standard (yet), but there seems to be reasonable support for this being a defect according to CWG discussion, and libstdc++ 7.1 relies on it working. llvm-svn: 304946
* Switch from using a DiagnosticTrap and a note for "while defining a specialRichard Smith2017-05-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | member function" context notes to registering an entry on the context stack. Also reorder the steps within defining special members to be consistent. This has a few benefits: if multiple diagnostics are produced while checking such a member, the note is now attached to the first such diagnostic rather than the last, this prepares us for persisting these diagnostics between the point at which we require the implicit instantiation of a template and the point at which that instantiation is actually performed, and this fixes some cases where we would fail to produce a full note stack leading back to user code in the case of such a diagnostic. The reordering exposed a case where we could recursively attempt to define a defaulted destructor while we're already defining one (and other such cases also appear to be possible, with or without this change), so this change also reuses the "willHaveBody" flag on function declarations to track that we're in the middle of synthesizing a body for the function and bails out if we try to define a function that we're already defining. llvm-svn: 303930
* [Sema] Implement Core 2094: Trivial copy/move constructor for class with ↵Eric Fiselier2017-05-092-4/+33
| | | | | | | | | | | | | | | | volatile member 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 llvm-svn: 302593
* [modules ts] Diagnose 'export' declarations outside of a module interface.Richard Smith2017-04-241-0/+27
| | | | llvm-svn: 301271
* Rearrange some Modules TS testcases into test/CXX/modules-ts.Richard Smith2017-04-223-0/+119
| | | | llvm-svn: 301066
* Correct class-template deprecation behavior-REDUXErich Keane2017-03-231-3/+34
| | | | | | | | | | | | | | | | | | Correct class-template deprecation behavior Based on the comment in the test, and my reading of the standard, a deprecated warning should be issued in the following case: template<typename T> [[deprecated]] class Foo{}; Foo<int> f; This was not the case, because the ClassTemplateSpecializationDecl creation did not also copy the deprecated attribute. Note: I did NOT audit the complete set of attributes to see WHICH ones should be copied, so instead I simply copy ONLY the deprecated attribute. Previous DiffRev: https://reviews.llvm.org/D27486, was reverted. This patch fixes the issues brought up here by the reverter: https://reviews.llvm.org/rL298410 Differential Revision: https://reviews.llvm.org/D31245 llvm-svn: 298634
* Revert "Correct class-template deprecation behavior"Martin Bohme2017-03-221-34/+3
| | | | | | | This reverts commit r298410 (which produces incorrect warnings, see comments on https://reviews.llvm.org/rL298410). llvm-svn: 298504
* Correct class-template deprecation behaviorErich Keane2017-03-211-3/+34
| | | | | | | | | | | | | Based on the comment in the test, and my reading of the standard, a deprecated warning should be issued in the following case: template<typename T> [[deprecated]] class Foo{}; Foo<int> f; This was not the case, because the ClassTemplateSpecializationDecl creation did not also copy the deprecated attribute. Note: I did NOT audit the complete set of attributes to see WHICH ones should be copied, so instead I simply copy ONLY the deprecated attribute. Differential Revision: https://reviews.llvm.org/D27486 llvm-svn: 298410
* Implement DR 373 "Lookup on namespace qualified name in using-directive"Matthias Gehre2017-03-171-5/+8
| | | | | | | | | | | | | | 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 llvm-svn: 298126
* Print nested name specifiers for typedefs and type aliasesAlex Lorenz2017-03-103-6/+6
| | | | | | | | | | | | Printing typedefs or type aliases using clang_getTypeSpelling() is missing the namespace they are defined in. This is in contrast to other types that always yield the full typename including namespaces. Patch by Michael Reiher! Differential Revision: https://reviews.llvm.org/D29944 llvm-svn: 297465
* C++ DR1611, 1658, 2180: implement "potentially constructed subobject" rules ↵Richard Smith2017-02-252-0/+142
| | | | | | | | | | | | | | | | | | | | | | for special member functions. Essentially, as a base class constructor does not construct virtual bases, such a constructor for an abstract class does not need the corresponding base class construction to be valid, and likewise for destructors. This creates an awkward situation: clang will sometimes generate references to the complete object and deleting destructors for an abstract class (it puts them in the construction vtable for a derived class). But we can't generate a "correct" version of these because we can't generate references to base class constructors any more (if they're template specializations, say, we might not have instantiated them and can't assume any other TU will emit a copy). Fortunately, we don't need to, since no correct program can ever invoke them, so instead emit symbols that just trap. We should stop emitting references to these symbols, but still need to emit definitions for compatibility. llvm-svn: 296275
* Add context note to diagnostics that occur while declaring an implicit ↵Richard Smith2017-02-231-3/+5
| | | | | | special member function. llvm-svn: 296020
* Fix tracking of whether the previous template instantiation stack matches ↵Richard Smith2017-02-231-3/+1
| | | | | | | | | | | | | | | | | the current one. Rather than attempting to compare whether the previous and current top of context stack are "equal" (which fails for a number of reasons, such as the context stack entries containing pointers to objects on the stack, or reaching the same "top of stack" entry through two different paths), track the depth of context stack at which we last emitted a note and invalidate it when we pop the context stack to less than that depth. This causes us to emit some missing "in instantiation of" notes and to stop emitting redundant "in instantiation of" stacks matching the previous stack in rare cases. llvm-svn: 295921
* Revert r295277 to fix buildbot.Richard Smith2017-02-161-1/+1
| | | | llvm-svn: 295281
* Add missing "deduced A == A" check for function template partial ordering.Richard Smith2017-02-161-1/+1
| | | | | | | | | This appears to be the only template argument deduction context where we were missing this check. Surprisingly, other implementations also appear to miss the check in this case; it may turn out that important code is relying on the widespread non-conformance here, in which case we'll need to reconsider. llvm-svn: 295277
* [Sema] Add lvalue-to-rvalue cast in direct-list-initialization of enumVedant Kumar2017-02-161-14/+31
| | | | | | | | | | | | | | | | | After r264564, we allowed direct-list-initialization of an enum from an integral value in C++1z mode, so long as that value can convert to the enum's underlying type. In this kind of initialization, we need a lvalue-to-rvalue conversion for the initializer value if it is not a rvalue. This lets us accept the following code: enum class A : unsigned {}; A foo(unsigned x) { return A{x}; } Differential Revision: https://reviews.llvm.org/D29723 llvm-svn: 295266
* [c++1z] Add some more tests for class template argument deduction, addRichard Smith2017-02-142-1/+40
| | | | | | feature-test macro, and mark feature as done on status page. llvm-svn: 295011
* [c++1z] Synthesize implicit deduction guides from constructors on demand. RankRichard Smith2017-02-143-19/+47
| | | | | | | | | | | | | | | | | | | 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
* [c++1z] Diagnose attempts to use variables with deduced class templateRichard Smith2017-02-103-8/+16
| | | | | | specialization types from within their own initializers. llvm-svn: 294796
* [c++1z] Require an initializer for deduced class template specialization types.Richard Smith2017-02-104-6/+12
| | | | | | | | 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
* [c++1z] Enforce restriction that deduction guide is declared in the same ↵Richard Smith2017-02-101-10/+10
| | | | | | scope as its template. llvm-svn: 294778
* [c++1z] Disallow deduction guides with deduced types that don't ↵Richard Smith2017-02-101-5/+3
| | | | | | syntactically match the template being deduced. llvm-svn: 294773
* [c++1z] In class template argument deduction, all declarators must deduce ↵Richard Smith2017-02-101-0/+12
| | | | | | the same type (just like with auto deduction). llvm-svn: 294700
* [Concepts] Class template associated constraintsHubert Tong2017-02-101-0/+65
| | | | | | | | | | | | | | | | 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
* [c++1z] P0512R0: support for 'explicit' specifier on deduction-guides.Richard Smith2017-02-102-2/+27
| | | | llvm-svn: 294693
* Disallow explicit instantiation and explicit specialization for deduction ↵Richard Smith2017-02-091-0/+20
| | | | | | guides. llvm-svn: 294641
* [c++1z] P0091R3: Basic support for deducing class template arguments via ↵Richard Smith2017-02-093-1/+55
| | | | | | deduction-guides. llvm-svn: 294613
* Sema: add warning for c++ member variable shadowingSaleem Abdulrasool2017-02-083-11/+123
| | | | | | | | | | 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
* Diagnose an attempt to give a deduction-guide a function body.Richard Smith2017-02-081-5/+5
| | | | llvm-svn: 294397
* Fix constructor declarator detection for the case when the name is followed byRichard Smith2017-02-081-1/+1
| | | | | | an attribute-specifier-seq. (Also fixes the same problem for deduction-guides.) llvm-svn: 294396
* P0091R3: Improved syntactic checking of deduction-guides.Richard Smith2017-02-082-11/+26
| | | | llvm-svn: 294395
* P0091R3: Implement basic parsing support for C++17 deduction-guides.Richard Smith2017-02-073-0/+161
| | | | | | | | | | | 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
* Repoint 'missing typename' diagnostic to the location where 'typename' ↵Richard Smith2017-02-011-1/+2
| | | | | | should be added. llvm-svn: 293817
* Fix hole in our enforcement of rule requiring 'typename' prior to a dependentRichard Smith2017-02-013-3/+44
| | | | | | | | | | | 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
* PR0091R3: Implement parsing support for using templates as types.Richard Smith2017-01-262-3/+15
| | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud