summaryrefslogtreecommitdiffstats
path: root/clang/test/CXX/basic
Commit message (Collapse)AuthorAgeFilesLines
* Add -std=c++20 flag, replace C++2a with C++20 throughout the ClangRichard Smith2020-02-191-2/+2
| | | | | | | | | | | | | user interface and documentation, and update __cplusplus for C++20. WG21 considers the C++20 standard to be finished (even though it still has some more steps to pass through in the ISO process). The old flag names are accepted for compatibility, as usual, and we still have lots of references to C++2a in comments and identifiers; those can be cleaned up separately. (cherry picked from commit 24ad121582454e625bdad125c90d9ac0dae948c8)
* When diagnosing the lack of a viable conversion function, also listRichard Smith2020-01-091-1/+1
| | | | | | | | | | | | | | explicit functions that are not candidates. It's not always obvious that the reason a conversion was not possible is because the function you wanted to call is 'explicit', so explicitly say if that's the case. It would be nice to rank the explicit candidates higher in the diagnostic if an implicit conversion sequence exists for their arguments, but unfortunately we can't determine that without potentially triggering non-immediate-context errors that we're not permitted to produce.
* C++ DR712 and others: handle non-odr-use resulting from an lvalue-to-rvalue ↵Richard Smith2019-06-141-0/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | conversion applied to a member access or similar not-quite-trivial lvalue expression. Summary: When a variable is named in a context where we can't directly emit a reference to it (because we don't know for sure that it's going to be defined, or it's from an enclosing function and not captured, or the reference might not "work" for some reason), we emit a copy of the variable as a global and use that for the known-to-be-read-only access. This reinstates r363295, reverted in r363352, with a fix for PR42276: we now produce a proper name for a non-odr-use reference to a static constexpr data member. The name <mangled-name>.const is used in that case; such names are reserved to the implementation for cases such as this and should demangle nicely. Reviewers: rjmccall Subscribers: jdoerfert, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D63157 llvm-svn: 363428
* Revert 363295, it caused PR42276. Also revert follow-ups 363337, 363340.Nico Weber2019-06-141-80/+0
| | | | | | | | Revert 363340 "Remove unused SK_LValueToRValue initialization step." Revert 363337 "PR23833, DR2140: an lvalue-to-rvalue conversion on a glvalue of type" Revert 363295 "C++ DR712 and others: handle non-odr-use resulting from an lvalue-to-rvalue conversion applied to a member access or similar not-quite-trivial lvalue expression." llvm-svn: 363352
* C++ DR712 and others: handle non-odr-use resulting from an lvalue-to-rvalue ↵Richard Smith2019-06-131-0/+80
| | | | | | | | | | | | | | | | | | | | | conversion applied to a member access or similar not-quite-trivial lvalue expression. Summary: When a variable is named in a context where we can't directly emit a reference to it (because we don't know for sure that it's going to be defined, or it's from an enclosing function and not captured, or the reference might not "work" for some reason), we emit a copy of the variable as a global and use that for the known-to-be-read-only access. Reviewers: rjmccall Subscribers: jdoerfert, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D63157 llvm-svn: 363295
* [c++20] Implement P0846R0: allow (ADL-only) calls to template-ids whoseRichard Smith2019-05-091-9/+51
| | | | | | | | | | | | | | | | | | | | | | | | | template name is not visible to unqualified lookup. In order to support this without a severe degradation in our ability to diagnose typos in template names, this change significantly restructures the way we handle template-id-shaped syntax for which lookup of the template name finds nothing. Instead of eagerly diagnosing an undeclared template name, we now form a placeholder template-name representing a name that is known to not find any templates. When the parser sees such a name, it attempts to disambiguate whether we have a less-than comparison or a template-id. Any diagnostics or typo-correction for the name are delayed until its point of use. The upshot should be a small improvement of our diagostic quality overall: we now take more syntactic context into account when trying to resolve an undeclared identifier on the left hand side of a '<'. In fact, this works well enough that the backwards-compatible portion (for an undeclared identifier rather than a lookup that finds functions but no function templates) is enabled in all language modes. llvm-svn: 360308
* [Sema] ADL: Associated namespaces for class types and enumeration types (CWG ↵Bruno Ricci2019-04-221-5/+13
| | | | | | | | | | | | | | | | | | | 1691) CWG 1691 changed the definition of the namespaces associated with a class type or enumeration type. For a class type, the associated namespaces are the innermost enclosing namespaces of the associated classes. For an enumeration type, the associated namespace is the innermost enclosing namespace of its declaration. This also fixes CWG 1690 and CWG 1692. Differential Revision: https://reviews.llvm.org/D60573 Reviewed By: rjmccall, rsmith llvm-svn: 358882
* [Sema][NFC] Add more tests for the behavior of argument-dependent name lookupBruno Ricci2019-04-225-0/+565
| | | | | | | | | | | | | | | | | | | | | | | The goal here is to exercise each rule in [basic.lookup.argdep] at least once. These new tests expose what I believe are 2 issues: 1. CWG 1691 needs to be implemented (p2: [...] Its associated namespaces are the innermost enclosing namespaces of its associated classes [...]) The corresponding tests are adl_class_type::X2 and adl_class_type::X5. 2. The end of paragraph 2 ([...] Additionally, if the aforementioned set of overloaded functions is named with a template-id, its associated classes and namespaces also include those of its type template-arguments and its template template-arguments.) is not implemented. Closely related, the restriction on non-dependent parameter types in this same paragraph needs to be removed. The corresponding tests are in adl_overload_set (both issues are from CWG 997). Differential Revision: https://reviews.llvm.org/D60570 Reviewed By: riccibruno, Quuxplusone llvm-svn: 358881
* [c++2a] Add semantic support for private module fragments.Richard Smith2019-04-182-10/+46
| | | | llvm-svn: 358713
* [c++2a] Improve diagnostic for use of declaration from another TU'sRichard Smith2019-04-181-0/+86
| | | | | | | | | | global module fragment. We know that the declaration in question should have been introduced by a '#include', so try to figure out which one and suggest it. Don't suggest importing the global module fragment itself! llvm-svn: 358631
* [c++20] Parsing support for module-declarations, import-declarations,Richard Smith2019-04-142-0/+90
| | | | | | | | | and the global and private module fragment. For now, the private module fragment introducer is ignored, but use of the global module fragment introducer should be properly enforced. llvm-svn: 358353
* Restore pre-r335182 behavior for naming inherited constructors asRichard Smith2018-06-221-0/+15
| | | | | | | | | | | | | | members of dependent contexts. This permits cases where the names before and after the '::' in a dependent inherited constructor using-declaration do not match, but where we can nonetheless tell when parsing the template that a constructor is being named. Under (open) core language DR 2070, such cases will probably be ill-formed, but r335182 does not quite give that result and didn't intend to change this, so restore the old behavior for now. llvm-svn: 335381
* Add a "vexing parse" warning for ambiguity between a variable declaration and aRichard Smith2017-09-291-0/+1
| | | | | | | | | | | | | | function-style cast. This fires for cases such as T(x); ... where 'x' was previously declared and T is a type. This construct declares a variable named 'x' rather than the (probably expected) interpretation of a function-style cast of 'x' to T. llvm-svn: 314570
* Correctly compute linkage for members of internal linkage classes.Richard Smith2017-09-231-0/+9
| | | | | | | We used to give such members no linkage instead of giving them the linkage of the class. llvm-svn: 314054
* DR1113: anonymous namespaces formally give their contents internal linkage.Richard Smith2017-09-221-0/+7
| | | | | | | | | | | | | | | | | | | | This doesn't affect our code generation in any material way -- we already give such declarations internal linkage from a codegen perspective -- but it has some subtle effects on code validity. We suppress the 'L' (internal linkage) marker for mangled names in anonymous namespaces, because it is redundant (the information is already carried by the namespace); this deviates from GCC's behavior if a variable or function in an anonymous namespace is redundantly declared 'static' (where GCC does include the 'L'), but GCC's behavior is incoherent because such a declaration can be validly declared with or without the 'static'. We still deviate from the standard in one regard here: extern "C" declarations in anonymous namespaces are still granted external linkage. Changing those does not appear to have been an intentional consequence of the standard change in DR1113. llvm-svn: 314037
* Closure types have no name (and can't have a typedef name for linkageRichard Smith2017-09-221-11/+4
| | | | | | purposes), so they never formally have linkage. llvm-svn: 313957
* Implement C++ [basic.link]p8.Richard Smith2017-09-201-0/+69
| | | | | | | | | | | | | | If a function or variable has a type with no linkage (and is not extern "C"), any use of it requires a definition within the same translation unit; the idea is that it is not possible to define the entity elsewhere, so any such use is necessarily an error. There is an exception, though: some types formally have no linkage but nonetheless can be referenced from other translation units (for example, this happens to anonymous structures defined within inline functions). For entities with those types, we suppress the diagnostic except under -pedantic. llvm-svn: 313729
* Add IDNS_Tag to C++ declarations that conflict with tag declarations.Richard Smith2017-09-071-0/+19
| | | | | | | Fixes some accepts-invalids with tags and other declarations declared in the same scope. llvm-svn: 312743
* Print nested name specifiers for typedefs and type aliasesAlex Lorenz2017-03-101-1/+1
| | | | | | | | | | | | 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
* Fix hole in our enforcement of rule requiring 'typename' prior to a dependentRichard Smith2017-02-011-2/+6
| | | | | | | | | | | 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
* Finish implementation of C++ DR1310 (http://wg21.link/cwg1310).Richard Smith2017-01-201-3/+1
| | | | | | | Diagnose the case when a dependent template name instantiates to an injected-class-name outside a nested-name-specifier. llvm-svn: 292545
* PR13403 (+duplicates): implement C++ DR1310 (http://wg21.link/cwg1310).Richard Smith2017-01-191-4/+85
| | | | | | | | | | | | | | | | | | | | | | 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
* Allow constexpr construction of subobjects unconditionally, not just in C++14.David L. Jones2017-01-091-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Improve error message when referencing a non-tag type with a tagReid Kleckner2016-12-091-2/+2
| | | | | | | | | | | | | | | | | | | | 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
* Re-commit r283722, reverted in r283750, with a fix for a CUDA-specific use ofRichard Smith2016-10-101-0/+19
| | | | | | | | | | | past-the-end iterator. Original commit message: P0035R4: Semantic analysis and code generation for C++17 overaligned allocation. llvm-svn: 283789
* Revert "P0035R4: Semantic analysis and code generation for C++17 overaligned ↵Daniel Jasper2016-10-101-19/+0
| | | | | | | | | | | | 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
* P0035R4: Semantic analysis and code generation for C++17 overalignedRichard Smith2016-10-101-0/+19
| | | | | | allocation. llvm-svn: 283722
* Don't diagnoes a mismatch between implicit and explicit exceptionRichard Smith2016-08-312-3/+18
| | | | | | | specifications under -fno-exceptions, just as we don't diagnose other exception specification mismatch errors. llvm-svn: 280289
* P0136R1, DR1573, DR1645, DR1715, DR1736, DR1903, DR1941, DR1959, DR1991:Richard Smith2016-06-282-4/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Replace inheriting constructors implementation with new approach, voted into C++ last year as a DR against C++11. Instead of synthesizing a set of derived class constructors for each inherited base class constructor, we make the constructors of the base class visible to constructor lookup in the derived class, using the normal rules for using-declarations. For constructors, UsingShadowDecl now has a ConstructorUsingShadowDecl derived class that tracks the requisite additional information. We create shadow constructors (not found by name lookup) in the derived class to model the actual initialization, and have a new expression node, CXXInheritedCtorInitExpr, to model the initialization of a base class from such a constructor. (This initialization is special because it performs real perfect forwarding of arguments.) In cases where argument forwarding is not possible (for inalloca calls, variadic calls, and calls with callee parameter cleanup), the shadow inheriting constructor is not emitted and instead we directly emit the initialization code into the caller of the inherited constructor. Note that this new model is not perfectly compatible with the old model in some corner cases. In particular: * if B inherits a private constructor from A, and C uses that constructor to construct a B, then we previously required that A befriends B and B befriends C, but the new rules require A to befriend C directly, and * if a derived class has its own constructors (and so its implicit default constructor is suppressed), it may still inherit a default constructor from a base class llvm-svn: 274049
* Implement C++17 P0386R2, inline variables. (The 'inline' specifier gives aRichard Smith2016-06-252-0/+14
| | | | | | | variable weak discardable linkage and partially-ordered initialization, and is implied for constexpr static data members.) llvm-svn: 273754
* Lit C++11 Compatibility Patch #8Charles Li2016-04-141-3/+14
| | | | | | 24 tests have been updated for C++11 compatibility. llvm-svn: 266387
* [Lit Test] Updated 34 Lit tests to be C++11 compatible.Charles Li2015-11-173-4/+27
| | | | | | | Added expected diagnostics new to C++11. Expanded RUN line to: default, C++98/03 and C++11. llvm-svn: 253371
* [Sema] main can't be declared as global variable, in C++.Davide Italiano2015-08-141-0/+66
| | | | | | | | | | | So, we now reject that. We also warn for any external-linkage global variable named main in C, because it results in undefined behavior. PR: 24309 Differential Revision: http://reviews.llvm.org/D11658 Reviewed by: rsmith llvm-svn: 245051
* [Sema] Don't crash if array bound calculation overflowed constexpr arrayDavid Majnemer2015-04-181-0/+2
| | | | | | | | | We didn't correctly expect a QualifiedTypeLoc when faced with fixing a variable array type into a constant array type. Differential Revision: http://reviews.llvm.org/D8958 llvm-svn: 235251
* Update error message text.Serge Pavlov2015-01-181-1/+1
| | | | | | | | | Previously if an enumeration was used in a nested name specifier in pre-C++11 language dialect, error message was 'XXX is not a class, namespace, or scoped enumeration'. This patch removes the word 'scoped' as in C++11 any enumeration may be used in this context. llvm-svn: 226410
* DR1684: a constexpr member function need not be a member of a literal class ↵Richard Smith2014-12-161-6/+5
| | | | | | type. llvm-svn: 224388
* Revert "clang/test/Driver/crash-report.c: This requires rewriter for ↵Alp Toker2014-07-161-1/+0
| | | | | | | | | | | | | | | | | | | | | -frewrite-includes. [PR20321]" We've decided to make the core rewriter class and PP rewriters mandatory. They're only a few hundred lines of code in total and not worth supporting as a distinct build configuration, especially since doing so disables key compiler features. This reverts commit r213150. Revert "clang/test: Introduce the feature "rewriter" for --enable-clang-rewriter." This reverts commit r213148. Revert "Move clang/test/Frontend/rewrite-*.c to clang/test/Frontend/Rewriter/" This reverts commit r213146. llvm-svn: 213159
* clang/test: Introduce the feature "rewriter" for --enable-clang-rewriter.NAKAMURA Takumi2014-07-161-0/+1
| | | | llvm-svn: 213148
* Don't accept qualified 'int' main return types in C++ or standard C modeAlp Toker2014-07-021-0/+2
| | | | | | | | | C++ [basic.start.main]p1: "It shall have a return type of type int" ISO C is also clear about this, so only accept 'int' with qualifiers in GNUMode C. llvm-svn: 212171
* The exception-declaration for a function-try-block cannot redeclare aAaron Ballman2014-06-022-4/+14
| | | | | | | function parameter. One of our existing test cases was XFAILed because of this. This fixes the issue and un-XFAILs the test. llvm-svn: 210026
* This test should no longer be XFAILed; the standard has stabilized, and the ↵Aaron Ballman2014-05-301-13/+12
| | | | | | test contents are acceptable. No diagnostics expected from this test. llvm-svn: 209891
* Test requires exceptionsAlp Toker2014-05-281-1/+1
| | | | | | It's still XFAIL, but slightly closer to passing. llvm-svn: 209729
* Sema: Implement DR244David Majnemer2014-05-211-1/+2
| | | | | | | | | | | | | | | | Summary: Naming the destructor using a typedef-name for the class-name is well-formed. This fixes PR19620. Reviewers: rsmith, doug.gregor Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D3583 llvm-svn: 209319
* Revert "Sema: Implement DR244"David Majnemer2014-05-031-2/+1
| | | | | | | | This was accidentally committed. This reverts commit r207892. llvm-svn: 207893
* Sema: Implement DR244David Majnemer2014-05-031-1/+2
| | | | | | | | | Naming the destructor using a typedef-name for the class-name is well-formed. This fixes PR19620. llvm-svn: 207892
* Don't fold together the name lookup entries for two declarations if they areRichard Smith2014-03-171-0/+11
| | | | | | declared in different namespaces in the same inline namespace set. llvm-svn: 204082
* Improve diagnostic for using non-class/namespace/scoped enum in a nested ↵David Blaikie2014-02-091-1/+2
| | | | | | | | | | | | | | | name specifier. Rather than simply saying "X is not a class or namespace", clarify what X is by providing the aka type in the case where X is a type, or pointing to the named declaration if there's an unambiguous one to refer to. In the ambiguous case, the ambiguities are already enumerated (though could be clarified by describing what kind of entities they are) Included a few FIXMEs in tests where some further improvements could be made. llvm-svn: 201038
* Add implicit declarations of allocation functions when looking them up forRichard Smith2014-02-042-2/+4
| | | | | | | | redeclaration, not just when looking them up for a use -- we need the implicit declaration to appropriately check various properties of them (notably, whether they're deleted). llvm-svn: 200729
* Add a test file missed from r199782.Richard Smith2014-01-221-0/+24
| | | | llvm-svn: 199783
* Added warning on structures/unions that are empty or contain onlySerge Pavlov2013-11-141-1/+1
| | | | | | | | | | bit fields of zero size. Warnings are generated in C++ mode and if only such type is defined inside extern "C" block. The patch fixed PR5065. Differential Revision: http://llvm-reviews.chandlerc.com/D2151 llvm-svn: 194653
OpenPOWER on IntegriCloud