summaryrefslogtreecommitdiffstats
path: root/clang/test/CXX/dcl.dcl
Commit message (Collapse)AuthorAgeFilesLines
* Add -std=c++20 flag, replace C++2a with C++20 throughout the ClangRichard Smith2020-02-193-60/+60
| | | | | | | | | | | | | 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 an ambiguity, only note the candidates that contributeRichard Smith2019-10-241-11/+11
| | | | to the ambiguity, rather than noting all viable candidates.
* For P0784R7: compute whether a variable has constant destruction if itRichard Smith2019-09-291-0/+17
| | | | | | | | | | has a constexpr destructor. For constexpr variables, reject if the variable does not have constant destruction. In all cases, do not emit runtime calls to the destructor for variables with constant destruction. llvm-svn: 373159
* For P0784R7: add further testing of requirements on constexprRichard Smith2019-09-231-0/+68
| | | | | | destructors. llvm-svn: 372541
* For P0784R7: add support for constexpr destructors, and call them asRichard Smith2019-09-232-3/+10
| | | | | | | | | | | appropriate during constant evaluation. Note that the evaluator is sometimes invoked on incomplete expressions. In such cases, if an object is constructed but we never reach the point where it would be destroyed (and it has non-trivial destruction), we treat the expression as having an unmodeled side-effect. llvm-svn: 372538
* [c++20] P1331R2: Allow transient use of uninitialized objects inRichard Smith2019-09-182-17/+45
| | | | | | constant evaluation. llvm-svn: 372237
* [MS] Consder constexpr globals to be inline, as in C++17Reid Kleckner2019-09-111-4/+8
| | | | | | | | | | | | | | | | Summary: Microsoft seems to do this regardless of the language mode, so we must also do it in order to be ABI compatible. Fixes PR36125 Reviewers: thakis Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D47956 llvm-svn: 371642
* [c++20] P1143R2: Add support for the C++20 'constinit' keyword.Richard Smith2019-09-043-0/+69
| | | | | | | | | | | | | This is mostly the same as the [[clang::require_constant_initialization]] attribute, but has a couple of additional syntactic and semantic restrictions. In passing, I added a warning for the attribute form being added after we have already seen the initialization of the variable (but before we see the definition); that case previously slipped between the cracks and the attribute was silently ignored. llvm-svn: 370972
* Implement P1668R1Erich Keane2019-08-191-2/+6
| | | | | | | Allow inline assembly statements in unexecuted branches of constexpr functions. llvm-svn: 369281
* When determining whether a lambda-expression is implicitly constexpr,Richard Smith2019-07-291-4/+1
| | | | | | | | | | | | check the formal rules rather than seeing if the normal checks produce a diagnostic. This fixes the handling of C++2a extensions in lambdas in C++17 mode, as well as some corner cases in earlier language modes where we issue diagnostics for things other than not satisfying the formal constexpr requirements. llvm-svn: 367254
* Implement P1771Erich Keane2019-07-251-0/+50
| | | | | | | | | | | | | As passed in the Cologne meeting and treated by Core as a DR, [[nodiscard]] was applied to constructors so that they can be diagnosed in cases where the user forgets a variable name for a type. The intent is to enable the library to start using this on the constructors of scope_guard/lock_guard. Differential Revision: https://reviews.llvm.org/D64914 llvm-svn: 367027
* Implement P1301R4, which allows specifying an optional message on the ↵Aaron Ballman2019-07-202-7/+31
| | | | | | | | [[nodiscard]] attribute. This also bumps the attribute feature test value and introduces the notion of a C++2a extension warning. llvm-svn: 366626
* [CXX] Exercise all paths through these tests.Paul Robinson2019-07-091-0/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D63894 llvm-svn: 365555
* [c++20] P1330R0: permit simple-assignments that change the active memberRichard Smith2019-05-211-1/+1
| | | | | | of a union within constant expression evaluation. llvm-svn: 361329
* [c++20] P1064R0: Allow virtual function calls in constant expressionRichard Smith2019-05-131-5/+17
| | | | | | | | | | | | | evaluation. This reinstates r360559, reverted in r360580, with a fix to avoid crashing if evaluation-for-overflow mode encounters a virtual call on an object of a class with a virtual base class, and to generally not try to resolve virtual function calls to objects whose (notional) vptrs are not readable. (The standard rules are unclear here, but this seems like a reasonable approach.) llvm-svn: 360635
* Revert r360559 "[c++20] P1064R0: Allow virtual function calls in constant ↵Hans Wennborg2019-05-131-17/+5
| | | | | | | | | expression evaluation." This caused Chromium builds to hit the new "can't handle virtual calls with virtual bases" assert. Reduced repro coming up. llvm-svn: 360580
* [c++20] P1064R0: Allow virtual function calls in constant expressionRichard Smith2019-05-131-5/+17
| | | | | | evaluation. llvm-svn: 360559
* DR1872: don't allow any calls to virtual functions in constantRichard Smith2019-05-091-2/+2
| | | | | | | | evaluation. Not even in cases where we would not actually perform virtual dispatch. llvm-svn: 360370
* Do not warn on switches over enums that do not use [[maybe_unused]] enumeratorsDavid Blaikie2019-05-021-2/+16
| | | | | | | | | | PR36231, [dcl.attr.unused]p3 Reviewers: aaron.ballman Differential Revision: https://reviews.llvm.org/D61444 llvm-svn: 359800
* Add missing diagnostic for anonymous struct/union definitions that don'tRichard Smith2019-04-241-2/+2
| | | | | | introduce any names. llvm-svn: 359051
* Add a triple to this test so it passes for targets where alignof(double)Richard Smith2019-01-241-1/+1
| | | | | | really should be equal to alignof(float). llvm-svn: 352102
* Diagnose an unused result from a call through a function pointer whose ↵Aaron Ballman2019-01-031-0/+29
| | | | | | | | | | return type is marked [[nodiscard]]. When a function returns a type and that type was declared [[nodiscard]], we diagnose any unused results from that call as though the function were marked nodiscard. The same behavior should apply to calls through a function pointer. This addresses PR31526. llvm-svn: 350317
* [constexpr][c++2a] Try-catch blocks in constexpr functionsBruno Cardoso Lopes2018-12-102-7/+33
| | | | | | | | | | | | | | | | | | | | | | Implement support for try-catch blocks in constexpr functions, as proposed in http://wg21.link/P1002 and voted in San Diego for c++20. The idea is that we can still never throw inside constexpr, so the catch block is never entered. A try-catch block like this: try { f(); } catch (...) { } is then morally equivalent to just { f(); } Same idea should apply for function/constructor try blocks. rdar://problem/45530773 Differential Revision: https://reviews.llvm.org/D55097 llvm-svn: 348789
* Add missing temporary materialization conversion on left-hand side of .Richard Smith2018-07-271-1/+1
| | | | | | | | | in some member function calls. Specifically, when calling a conversion function, we would fail to create the AST node representing materialization of the class object. llvm-svn: 338135
* When a dependent alignas is applied to a non-dependent typedef,Richard Smith2018-06-201-0/+6
| | | | | | | prioritize the error for the bad subject over the error for the dependent / non-dependent mismatch. llvm-svn: 335191
* Allow [[maybe_unused]] on static data members; these are considered ↵Aaron Ballman2018-04-121-1/+1
| | | | | | | | variables and the attribute should appertain to them. Patch by S. B. Tam. llvm-svn: 329904
* [C++17] Fix class template argument deduction for default constructors ↵Zhihao Yuan2018-03-241-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | without an initializer Summary: As the title says, this makes following code compile: ``` template<typename> struct Foo {}; Foo() -> Foo<void>; Foo f; // ok ``` Thanks Nicolas Lesser for coining the fix. Reviewers: rsmith, lichray Reviewed By: rsmith, lichray Subscribers: lichray, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D38216 llvm-svn: 328409
* Bring r325915 back.Rafael Espindola2018-02-231-4/+4
| | | | | | | | | | | | | | | The tests that failed on a windows host have been fixed. Original message: Start setting dso_local for COFF. With this there are still some GVs where we don't set dso_local because setGVProperties is never called. I intend to fix that in followup commits. This is just the bare minimum to teach shouldAssumeDSOLocal what it should do for COFF. llvm-svn: 325940
* [Sema] Fix decltype of static data membersMikhail Maltsev2018-02-141-1/+6
| | | | | | | | | | | | | | | | | | | | | | | Summary: According to the C++11 standard [dcl.type.simple]p4: The type denoted by decltype(e) is defined as follows: - if e is an unparenthesized id-expression or an unparenthesized class member access (5.2.5), decltype(e) is the type of the entity named by e. Currently Clang handles the 'member access' case incorrectly for static data members (decltype returns T& instead of T). This patch fixes the issue. Reviewers: faisalv, rsmith, rogfer01 Reviewed By: rogfer01 Subscribers: rogfer01, cfe-commits Differential Revision: https://reviews.llvm.org/D42969 llvm-svn: 325117
* Determine the attribute subject for diagnostics based on declarative ↵Aaron Ballman2017-11-262-4/+4
| | | | | | | | | | information in DeclNodes.td. This greatly reduces the number of enumerated values used for more complex diagnostics; these are now only required when the "attribute only applies to" diagnostic needs to be generated manually as part of semantic processing. This also clarifies some terminology used by the diagnostic (methods -> Objective-C methods, fields -> non-static data members, etc). Many of the tests needed to be updated in multiple places for the diagnostic wording tweaks. The first instance of the diagnostic for that attribute is fully specified and subsequent instances cut off the complete list (to make it easier if additional subjects are added in the future for the attribute). llvm-svn: 319002
* Fix missing -Wregister warning when 'register' is applied to a function ↵Richard Smith2017-11-011-0/+1
| | | | | | parameter. llvm-svn: 317140
* Fix nodiscard for volatile referencesErich Keane2017-10-191-0/+12
| | | | | | | | | | As reported here https://bugs.llvm.org/show_bug.cgi?id=34988 [[nodiscard]] warnings were not being suppressed for volatile-ref return values. Differential Revision: https://reviews.llvm.org/D39075 llvm-svn: 316166
* This test case was missing -fsyntax-only, so I've added it. NFC to the ↵Aaron Ballman2017-10-171-1/+1
| | | | | | actual test contents, just how the test is executed. llvm-svn: 316028
* Replace remaining user-visible mentions of C++1z with C++17.Richard Smith2017-08-132-10/+10
| | | | llvm-svn: 310804
* 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
* 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
* [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] 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
* P0091R3: Improved syntactic checking of deduction-guides.Richard Smith2017-02-081-1/+1
| | | | llvm-svn: 294395
* PR0091R3: Implement parsing support for using templates as types.Richard Smith2017-01-261-1/+1
| | | | | | | | | | | | | | | 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
* PR31606: Generalize our tentative DR resolution for inheriting copy/moveRichard Smith2017-01-131-14/+14
| | | | | | constructors to better match the pre-P0136R1 behavior. llvm-svn: 291955
* Implement DR1265 (wg21.link/cwg1265).Richard Smith2017-01-131-7/+28
| | | | | | | | | | | | 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
* PR30305: Implement proposed DR resolution to prevent slicing via inherited ↵Richard Smith2017-01-081-3/+27
| | | | | | | | | | | | 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
* Fix name hiding and redeclaration checking for dependent localRichard Smith2016-12-181-20/+19
| | | | | | using-declarations. llvm-svn: 290072
* Fix some interactions between C++11 and C++14 features and using-declarations:Richard Smith2016-12-181-4/+154
| | | | | | | | | | | * 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
* Improve error message when referencing a non-tag type with a tagReid Kleckner2016-12-091-3/+3
| | | | | | | | | | | | | | | | | | | | 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
* Fix bogus "inline namespace cannot be reopened as non-inline" diagnostic toRichard Smith2016-09-301-2/+7
| | | | | | | just warn that the second declaration is missing the 'inline' keyword. This is valid, and we shouldn't be suggesting otherwise. llvm-svn: 282981
OpenPOWER on IntegriCloud