summaryrefslogtreecommitdiffstats
path: root/clang/test/CXX
Commit message (Collapse)AuthorAgeFilesLines
...
* [Sema] Classify conversions from enum to float as narrowingMikhail Maltsev2018-02-211-2/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: According to [dcl.init.list]p7: A narrowing conversion is an implicit conversion - ... - from an integer type or unscoped enumeration type to a floating-point type, except where the source is a constant expression and the actual value after conversion will fit into the target type and will produce the original value when converted back to the original type, or - ... Currently clang does not handle the 'unscoped enumeration' case. This patch fixes the corresponding check. Reviewers: faisalv, rsmith, rogfer01 Reviewed By: rogfer01 Subscribers: rogfer01, cfe-commits Differential Revision: https://reviews.llvm.org/D42545 llvm-svn: 325668
* Fix test failure on target where size_t is long long.Richard Smith2018-02-191-3/+6
| | | | llvm-svn: 325540
* [cxx_dr_status] Tests for CWG issues 641-687.Richard Smith2018-02-191-4/+671
| | | | llvm-svn: 325475
* [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
* [Parser][FixIt] Better diagnostics for "typedef" instead of "typename" typoJan Korous2018-02-081-14/+14
| | | | | | | | rdar://problem/10214588 Differential Revision: https://reviews.llvm.org/D42170 llvm-svn: 324607
* DR126: partially implement the const-correct rules for exception handler ↵Richard Smith2018-01-131-11/+26
| | | | | | | | | matching. While here, fix up the myriad other ways in which Sema's two "can this handler catch that exception?" implementations get things wrong and unify them. llvm-svn: 322431
* PR33503: When a qualified name in a redeclaration names a prior declaration inRichard Smith2018-01-031-0/+21
| | | | | | | | | | | an inline namespace, update its semantic DeclContext to match. We would previously get the semantic DeclContext wrong (pointing to the named scope rather than the inline namespace within it), resulting in wrong lookup results and linkage-related problems if the inline namespace was an anonymous namespace. llvm-svn: 321770
* [Sema] Improve diagnostics for const- and ref-qualified member functionsJacob Bandes-Storch2017-12-312-3/+37
| | | | | | | | | | | | | | | | | | | | | | | | (Re-submission of D39937 with fixed tests.) Adjust wording for const-qualification mismatch to be a little more clear. Also add another diagnostic for a ref qualifier mismatch, which previously produced a useless error (this error path is simply very old; see rL119336): Before: error: cannot initialize object parameter of type 'X0' with an expression of type 'X0' After: error: 'this' argument to member function 'rvalue' is an lvalue, but function has rvalue ref-qualifier Reviewers: aaron.ballman Reviewed By: aaron.ballman Subscribers: lebedev.ri, cfe-commits Differential Revision: https://reviews.llvm.org/D41646 llvm-svn: 321609
* Reverted 321592: [Sema] Improve diagnostics for const- and ref-qualified ↵Jacob Bandes-Storch2017-12-311-36/+2
| | | | | | | | member functions A few tests need to be fixed llvm-svn: 321593
* [Sema] Improve diagnostics for const- and ref-qualified member functionsJacob Bandes-Storch2017-12-311-2/+36
| | | | | | | | | | | | | | | | | | | | | | | Summary: Adjust wording for const-qualification mismatch to be a little more clear. Also add another diagnostic for a ref qualifier mismatch, which previously produced a useless error (this error path is simply very old; see rL119336): Before: error: cannot initialize object parameter of type 'X0' with an expression of type 'X0' After: error: 'this' argument to member function 'rvalue' is an lvalue, but function has rvalue ref-qualifier Reviewers: rsmith, aaron.ballman Reviewed By: aaron.ballman Subscribers: lebedev.ri, aaron.ballman, cfe-commits Differential Revision: https://reviews.llvm.org/D39937 llvm-svn: 321592
* Diagnose the various invalid decl-specifiers on nontype template parameters.Faisal Vali2017-12-221-3/+28
| | | | | | | | | | | | | The standard correctly forbids various decl-specifiers that dont make sense on non-type template parameters - such as the extern in: template<extern int> struct X; This patch implements those restrictions (in a fashion similar to the corresponding checks on function parameters within ActOnParamDeclarator). Credit goes to miyuki (Mikhail Maltsev) for drawing attention to this issue, authoring the initial versions of this patch, and supporting the effort to re-engineer it slightly. Thank you! For details of how this patch evolved please see: https://reviews.llvm.org/D40705 llvm-svn: 321339
* Re-commit r321223, which adds a printing policy to the ASTDumper.Aaron Ballman2017-12-211-56/+56
| | | | | | | | This allows you to dump C++ code that spells bool instead of _Bool, leaves off the elaborated type specifiers when printing struct or class names, and other C-isms. Fixes the -Wreorder issue and fixes the ast-dump-color.cpp test. llvm-svn: 321310
* Reverting r321223 and its follow-up commit because of failing bots due to ↵Aaron Ballman2017-12-201-56/+56
| | | | | | Misc/ast-dump-color.cpp. llvm-svn: 321229
* Add a printing policy to the ASTDumper.Aaron Ballman2017-12-201-56/+56
| | | | | | This allows you to dump C++ code that spells bool instead of _Bool, leaves off the elaborated type specifiers when printing struct or class names, and other C-isms. llvm-svn: 321223
* P0620 follow-up: deducing `auto` from braced-init-list in new exprZhihao Yuan2017-12-113-2/+25
| | | | | | | | | | | | | | | | | | | Summary: This is a side-effect brought in by p0620r0, which allows other placeholder types (derived from `auto` and `decltype(auto)`) to be usable in a `new` expression with a single-clause //braced-init-list// as its initializer (8.3.4 [expr.new]/2). N3922 defined its semantics. References: http://wg21.link/p0620r0 http://wg21.link/n3922 Reviewers: rsmith, aaron.ballman Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D39451 llvm-svn: 320401
* Remove old concepts parsing codeHubert Tong2017-12-071-0/+26
| | | | | | | | | | | | | | | | | | Summary: This is so we can implement concepts per P0734R0. Relevant failing test cases are disabled. Reviewers: hubert.reinterpretcast, rsmith, saar.raz, nwilson Reviewed By: saar.raz Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D40380 Patch by Changyu Li! llvm-svn: 319992
* Preserve the "last diagnostic was suppressed" flag across SFINAE checks.Richard Smith2017-11-301-0/+3
| | | | | | | | | | | | Sometimes we check the validity of some construct between producing a diagnostic and producing its notes. Ideally, we wouldn't do that, but in practice running code that "cannot possibly produce a diagnostic" in such a situation should be safe, and reasonable factoring of some code requires it with our current diagnostics infrastruture. If this does happen, a diagnostic that's suppressed due to SFINAE should not cause notes connected to the prior diagnostic to be suppressed. llvm-svn: 319408
* 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
* The offsetof macro is intended to work with subobjects rather than simple ↵Aaron Ballman2017-11-211-4/+4
| | | | | | identifiers designating a member, making the -Wextended-offsetof diagnostic obsolete as this construct is not an extension. Implements WG14 DR496. llvm-svn: 318796
* [Modules TS] Added module re-export support.Hamza Sood2017-11-211-0/+40
| | | | | | | This implements [dcl.modules.export] from the C++ Modules TS, which lets a module re-export another module with the "export import" syntax. Differential Revision: https://reviews.llvm.org/D40270 llvm-svn: 318744
* Fix missing -Wregister warning when 'register' is applied to a function ↵Richard Smith2017-11-011-0/+1
| | | | | | parameter. llvm-svn: 317140
* [C++17] Fix PR34970 - tweak overload resolution for class template ↵Faisal Vali2017-10-222-6/+37
| | | | | | | | | | | | | | | | | | | deduction-guides in line with WG21's p0620r0. In order to identify the copy deduction candidate, I considered two approaches: - attempt to determine whether an implicit guide is a copy deduction candidate by checking certain properties of its subsituted parameter during overload-resolution. - using one of the many bits (WillHaveBody) from FunctionDecl (that CXXDeductionGuideDecl inherits from) that are otherwise irrelevant for deduction guides After some brittle gymnastics w the first strategy, I settled on the second, although to avoid confusion and to give that bit a better name, i turned it into a member of an anonymous union. Given this identification 'bit', the tweak to overload resolution was a simple reordering of the deduction guide checks (in SemaOverload.cpp::isBetterOverloadCandidate), in-line with Jason Merrill's p0620r0 drafting which made it into the working paper. Concordant with that, I made sure the copy deduction candidate is always added. References: See https://bugs.llvm.org/show_bug.cgi?id=34970 See http://wg21.link/p0620r0 llvm-svn: 316292
* 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
* [Sema][Crash] Correctly handle an non-dependent noexcept expr in function ↵Erich Keane2017-10-121-0/+9
| | | | | | | | | | | | | | template It seems that all of the other templated cases are handled correctly, however the function template case was not correctly handled. This patch recovers from this condition by setting the function to noexcept after diagnosing. Previously it simply set NoexceptExpr to null, which caused an Assert when this was evaluated during substitution. Differential Revision:https://reviews.llvm.org/D38700 llvm-svn: 315638
* [Modules TS] Diagnose missing/duplicate module-declaration.Richard Smith2017-10-112-1/+15
| | | | llvm-svn: 315397
* [Modules TS] Diagnose attempts to enter module implementation units without ↵Richard Smith2017-10-104-11/+22
| | | | | | the module interface being available. llvm-svn: 315381
* [Modules TS] Module ownership semantics for redeclarations.Richard Smith2017-10-103-0/+118
| | | | | | | | | | | | | | | | | When declaring an entity in the "purview" of a module, it's never a redeclaration of an entity in the purview of a default module or in no module ("in the global module"). Don't consider those other declarations as possible redeclaration targets if they're not visible, and reject any cases where we pick a prior visible declaration that violates this rule. This reinstates r315251 and r315256, reverted in r315309 and r315308 respectively, tweaked to avoid triggering a linkage calculation when declaring implicit special members (this exposed our pre-existing issue with typedef names for linkage changing the linkage of types whose linkage has already been computed and cached in more cases). A testcase for that regression has been added in r315366. llvm-svn: 315379
* Revert "[Modules TS] Module ownership semantics for redeclarations."Eric Liu2017-10-103-118/+0
| | | | | | This reverts commit r315251. See the original commit thread for reason. llvm-svn: 315309
* [Modules TS] Module ownership semantics for redeclarations.Richard Smith2017-10-093-0/+118
| | | | | | | | | | When declaring an entity in the "purview" of a module, it's never a redeclaration of an entity in the purview of a default module or in no module ("in the global module"). Don't consider those other declarations as possible redeclaration targets if they're not visible, and reject any cases where we pick a prior visible declaration that violates this rule. llvm-svn: 315251
* Driver: hoist the `wchar_t` handling to the driverSaleem Abdulrasool2017-10-061-1/+1
| | | | | | | | | | | | | | | | Move the logic for determining the `wchar_t` type information into the driver. Rather than passing the single bit of information of `-fshort-wchar` indicate to the frontend the desired type of `wchar_t` through a new `-cc1` option of `-fwchar-type` and indicate the signedness through `-f{,no-}signed-wchar`. This replicates the current logic which was spread throughout Basic into the `RenderCharacterOptions`. Most of the changes to the tests are to ensure that the frontend uses the correct type. Add a new test set under `test/Driver/wchar_t.c` to ensure that we calculate the proper types for the various cases. llvm-svn: 315126
* 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
* Don't warn about runtime behavior problems in variable initializers that weRichard Smith2017-09-232-8/+8
| | | | | | | | know are going to be constant-evaluated. Any relevant diagnostics should be produced by constant expression evaluation. llvm-svn: 314067
* 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-222-0/+37
| | | | | | | | | | | | | | | | | | | | 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
* Fix tracking of whether a destructor would be deleted.Richard Smith2017-09-221-0/+21
| | | | | | | | | | I've been unable to find any cases whose behavior is actually changed by this, but only because an implicitly deleted destructor also results in it being impossible to have a trivial (non-deleted) copy constructor, which the place where this really matters (choosing whether to pass a class in registers) happens to also check. llvm-svn: 313948
* 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 target triple to improve the happiness of MSVC buildbots.Richard Smith2017-09-071-2/+2
| | | | llvm-svn: 312749
* 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
* P0702R1: in class template argument deduction from a list of one element, ifRichard Smith2017-09-071-0/+31
| | | | | | | that element's type is (or is derived from) a specialization of the deduced template, skip the std::initializer_list special case. llvm-svn: 312703
* [modules ts] Add test for [basic.link]p3.Richard Smith2017-09-071-0/+11
| | | | llvm-svn: 312696
* [modules ts] Ensure that module linkage variables are always emitted and ↵Richard Smith2017-09-072-6/+13
| | | | | | always have their name mangled. llvm-svn: 312684
* [modules ts] Emit global variables in a module interface unit as part of ↵Richard Smith2017-09-062-10/+6
| | | | | | that unit, not in importers. llvm-svn: 312665
* Implement Itanium name mangling support for C++ Modules TS.Richard Smith2017-09-044-31/+30
| | | | | | | | | | | | This follows the scheme agreed with Nathan Sidwell, which can be found here: https://gcc.gnu.org/wiki/cxx-modules?action=AttachFile This will be proposed to the itanium-cxx-abi list once we have some experience with how well it works; the ABI for this TS should be considered unstable until it is part of the Itanium C++ ABI. llvm-svn: 312467
* [modules] Add ability to specify module name to module file mapping (reapply)Boris Kolpackov2017-08-311-0/+39
| | | | | | | | | | | | | | | | | | | | Extend the -fmodule-file option to support the [<name>=]<file> value format. If the name is omitted, then the old semantics is preserved (the module file is loaded whether needed or not). If the name is specified, then the mapping is treated as just another prebuilt module search mechanism, similar to -fprebuilt-module-path, and the module file is only loaded if actually used (e.g., via import). With one exception: this mapping also overrides module file references embedded in other modules (which can be useful if module files are moved/renamed as often happens during remote compilation). This override semantics requires some extra work: we now store the module name in addition to the file name in the serialized AST representation. Reviewed By: rsmith Differential Revision: https://reviews.llvm.org/D35020 llvm-svn: 312220
* Fix path regex in test to match on WindowsBoris Kolpackov2017-08-311-1/+1
| | | | llvm-svn: 312217
* Revert r312105 [modules] Add ability to specify module name to module file ↵Victor Leschuk2017-08-301-39/+0
| | | | | | | | mapping Looks like it breaks win10 builder. llvm-svn: 312112
* [modules] Add ability to specify module name to module file mappingBoris Kolpackov2017-08-301-0/+39
| | | | | | | | | | | | | | | | | | | | Extend the -fmodule-file option to support the [<name>=]<file> value format. If the name is omitted, then the old semantics is preserved (the module file is loaded whether needed or not). If the name is specified, then the mapping is treated as just another prebuilt module search mechanism, similar to -fprebuilt-module-path, and the module file is only loaded if actually used (e.g., via import). With one exception: this mapping also overrides module file references embedded in other modules (which can be useful if module files are moved/renamed as often happens during remote compilation). This override semantics requires some extra work: we now store the module name in addition to the file name in the serialized AST representation. Reviewed By: rsmith Differential Revision: https://reviews.llvm.org/D35020 llvm-svn: 312105
* [modules-ts] Omit submodule semantics for TS modulesBoris Kolpackov2017-08-291-2/+7
| | | | | | | | | | | | If a TS module name has more than one component (e.g., foo.bar) then we erroneously activated the submodule semantics when encountering a module declaration in the module implementation unit (e.g., 'module foo.bar;'). Reviewed By: rsmith Differential Revision: https://reviews.llvm.org/D35678 llvm-svn: 312007
OpenPOWER on IntegriCloud