summaryrefslogtreecommitdiffstats
path: root/clang/test/CXX
Commit message (Collapse)AuthorAgeFilesLines
...
* Revert "DR583, DR1512: Implement a rewrite to C++'s 'composite pointer type' ↵Renato Golin2016-10-215-302/+17
| | | | | | | | rules." This reverts commit r284800, as it failed all ARM/AArch64 bots. llvm-svn: 284811
* DR583, DR1512: Implement a rewrite to C++'s 'composite pointer type' rules.Richard Smith2016-10-215-17/+302
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Re-commit r284753, reverted in r284778, with a fix for PR30749.Richard Smith2016-10-201-0/+51
| | | | | | | | | | 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
* Revert r284753 "[c++1z] Teach composite pointer type computation how to ↵Hans Wennborg2016-10-201-45/+0
| | | | | | | | compute the composite" It caused PR30749. llvm-svn: 284778
* [c++1z] Teach composite pointer type computation how to compute the compositeRichard Smith2016-10-201-0/+45
| | | | | | | 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
* DR1330: instantiate exception-specifications when "needed". We previously didRichard Smith2016-10-181-0/+85
| | | | | | | | | | | | | | | | | | | | 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
* clang/test/CXX/conv/conv.fctptr/p1.cpp: Appease for targeting i686-win32.NAKAMURA Takumi2016-10-161-1/+1
| | | | | | | 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
* P0012R1: Make exception specifications be part of the type system. ThisRichard Smith2016-10-1613-24/+240
| | | | | | | implements the bulk of the change (modifying the type system to include exception specifications), but not all the details just yet. llvm-svn: 284337
* Extend this test and make it a bit clearer which cases Clang is getting wrong.Richard Smith2016-10-161-14/+34
| | | | llvm-svn: 284331
* Re-commit r283722, reverted in r283750, with a fix for a CUDA-specific use ofRichard Smith2016-10-105-4/+185
| | | | | | | | | | | 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-105-185/+4
| | | | | | | | | | | | 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-105-4/+185
| | | | | | allocation. llvm-svn: 283722
* PR25890: Fix incoherent error handling in PerformImplicitConversion andRichard Smith2016-10-062-9/+8
| | | | | | | | | | | | 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
* 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
* P0035R4: add predefined __STDCPP_DEFAULT_NEW_ALIGNMENT__ macro. By default, weRichard Smith2016-09-301-0/+9
| | | | | | | | | 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
* P0035R4: add std::align_val_t overloads of operator new/delete in C++17 mode.Richard Smith2016-09-291-0/+6
| | | | llvm-svn: 282800
* Try contextually converting condition of constexpr if to Boolean valueIsmail Pazarbasi2016-09-071-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix clang's handling of the copy performed in the second phase of classRichard Smith2016-09-073-7/+7
| | | | | | | | | | | | | | | | | | | | | | | 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
* Fix all tests under test/CXX (and test/Analysis) to pass if clang's defaultRichard Smith2016-08-3110-56/+240
| | | | | | C++ language standard is not C++98. llvm-svn: 280309
* DR259: Demote the pedantic error for an explicit instantiation after anRichard Smith2016-08-313-29/+23
| | | | | | | | | 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
* 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
* Fix mishandling of deletedness for assignment operators of classes withRichard Smith2016-08-311-1/+2
| | | | | | | | 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
* PR28978: If we need overload resolution for the move constructor of anRichard Smith2016-08-161-0/+12
| | | | | | | | 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
* [C++1z] Fix crash when decomposing structs with anonymous members.Benjamin Kramer2016-08-121-0/+19
| | | | | | The diagnostic format was invalid. llvm-svn: 278487
* P0217R3: Constant expression evaluation for decomposition declarations.Richard Smith2016-08-123-3/+41
| | | | llvm-svn: 278447
* P0217R3: Perform semantic checks and initialization for the bindings in aRichard Smith2016-08-113-0/+398
| | | | | | | decomposition declaration for arrays, aggregate-like structs, tuple-like types, and (as an extension) for complex and vector types. llvm-svn: 278435
* Push alias-declarations and alias-template declarations into scope even ifRichard Smith2016-07-153-5/+5
| | | | | | | | 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
* [Sema] Fix a bug where pack expansion was not expanded in type aliasErik Pilkington2016-07-051-0/+32
| | | | | | | | | | 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
* [Sema] Implement C++14's DR1579: Prefer returning by converting move constructorErik Pilkington2016-06-301-0/+56
| | | | | | | | Fixes PR28096. Differential Revision: http://reviews.llvm.org/D21619 llvm-svn: 274291
* Mark inheriting constructors as deleted if the corresponding defaulted defaultRichard Smith2016-06-292-15/+15
| | | | | | | | 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
* [Sema] Disallow ambigious base classes in template argument deductionErik Pilkington2016-06-281-0/+13
| | | | | | | | Fixes PR28195. Differential revision: http://reviews.llvm.org/D21653 llvm-svn: 274077
* P0136R1, DR1573, DR1645, DR1715, DR1736, DR1903, DR1941, DR1959, DR1991:Richard Smith2016-06-2818-136/+744
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-258-6/+92
| | | | | | | variable weak discardable linkage and partially-ordered initialization, and is implied for constexpr static data members.) llvm-svn: 273754
* Using for attributes voted into C++17.Richard Smith2016-06-241-0/+16
| | | | llvm-svn: 273666
* Implement p0292r2 (constexpr if), a likely C++1z feature.Richard Smith2016-06-232-0/+184
| | | | llvm-svn: 273602
* Add test for DR1359.Richard Smith2016-06-131-0/+16
| | | | llvm-svn: 272575
* Fix recognition of shadowed template parameterSerge Pavlov2016-06-101-5/+16
| | | | | | | | | | | | | | | | | | | | | | | Crash reported in PR28023 is caused by the fact that non-type template parameters are found by tag name lookup. In the code provided in that PR: template<int V> struct A { struct B { template <int> friend struct V; }; }; the template parameter V is found when lookup for redeclarations of 'struct V' is made. Latter on the error about shadowing of 'V' is emitted but the semantic context of 'struct V' is already determined wrong: 'struct A' instead of translation unit. The fix moves the check for shadowing toward the beginning of the method and thus prevents from wrong context calculations. This change fixes PR28023. llvm-svn: 272366
* Warn when a reference is bound to an empty l-value (dereferenced null pointer).Nick Lewycky2016-05-141-2/+2
| | | | llvm-svn: 269572
* Add support for derived class special members hiding functions brought in fromRichard Smith2016-05-131-0/+32
| | | | | | | | | a base class via a using-declaration. If a class has a using-declaration declaring either a constructor or an assignment operator, eagerly declare its special members in case they need to displace a shadow declaration from a using-declaration. llvm-svn: 269398
* Add forgotten test from r268594.Richard Smith2016-05-051-0/+4
| | | | llvm-svn: 268665
* Add a FixItHint for the new diagnostic for a non-class-scope ↵Richard Smith2016-05-051-0/+27
| | | | | | using-declaration that names a class-scope enumerator. llvm-svn: 268664
* Fix implementation of C++'s restrictions on using-declarations referring to ↵Richard Smith2016-05-054-50/+85
| | | | | | | | | | | enumerators: * an unscoped enumerator whose enumeration is a class member is itself a class member, so can only be the subject of a class-scope using-declaration. * a scoped enumerator cannot be the subject of a class-scope using-declaration. llvm-svn: 268594
* [Parser] Clear the TemplateParamScope bit of the current scope's flagAkira Hatanaka2016-04-292-1/+5
| | | | | | | | | | | | | | | | | | | | | | | if we are parsing a template specialization. This commit makes changes to clear the TemplateParamScope bit and set the TemplateParamParent field of the current scope to null if a template specialization is being parsed. Before this commit, Sema::ActOnStartOfLambdaDefinition would check whether the parent template scope had any decls to determine whether or not a template specialization was being parsed. This wasn't correct since it couldn't distinguish between a real template specialization and a template defintion with an unnamed template parameter (only template parameters with names are added to the scope's decl list). To fix the bug, this commit changes the code to check the pointer to the parent template scope rather than the decl list. rdar://problem/23440346 Differential Revision: http://reviews.llvm.org/D19175 llvm-svn: 267975
* When deducing template parameters from base classes of an argument type, don'tRichard Smith2016-04-251-0/+14
| | | | | | | preserve any deduced types from a failed deduction to a subsequent attempt at deduction. Patch by Erik Pilkington! llvm-svn: 267444
* Revert the bool portion of r267054Richard Trieu2016-04-221-2/+2
| | | | | | | Remove the floating point to bool conversion warnings. Some of these conversions will be caught by -Wliteral-conversion and -Wfloat-conversion llvm-svn: 267234
* Split interesting warnings off from -Wfloat-conversionRichard Trieu2016-04-211-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Restructure the implict floating point to integer conversions so that interesting sub-groups are under different flags. Breakdown of warnings: No warning: Exact conversions from floating point to integer: int x = 10.0; int x = 1e10; -Wliteral-conversion - Floating point literal to integer with rounding: int x = 5.5; int x = -3.4; -Wfloat-conversion - All conversions not covered by the above two: int x = GetFloat(); int x = 5.5 + 3.5; -Wfloat-zero-conversion - The expression converted has a non-zero floating point value that gets converted to a zero integer value, excluded the cases falling under -Wliteral-conversion. Subset of -Wfloat-conversion. int x = 1.0 / 2.0; -Wfloat-overflow-conversion - The floating point value is outside the range of the integer type, exluding cases from -Wliteral conversion. Subset of -Wfloat-conversion. char x = 500; char x = -1000; -Wfloat-bool-conversion - Any conversion of a floating point type to bool. Subset of -Wfloat-conversion. if (GetFloat()) {} bool x = 5.0; -Wfloat-bool-constant-conversion - Conversion of a compile time evaluatable floating point value to bool. Subset of -Wfloat-bool-conversion. bool x = 1.0; bool x = 4.0 / 20.0; Also add EvaluateAsFloat to Sema, which is similar to EvaluateAsInt, but for floating point values. llvm-svn: 267054
* [Clang] Remove unwanted --check-prefix=CHECK from unit tests. NFC.Mandeep Singh Grang2016-04-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Removed unwanted --check-prefix=CHECK from the following unit tests: test/CXX/special/class.copy/implicit-move-def.cpp test/CodeGen/cleanup-destslot-simple.c test/CodeGen/inline-asm-immediate-ubsan.c test/CodeGen/mips-interrupt-attr.c test/CodeGenCXX/cfi-stats.cpp test/CodeGenCXX/copy-constructor-elim.cpp test/CodeGenCXX/microsoft-templ-uuidof.cpp test/CodeGenCXX/vtable-linkage.cpp test/CodeGenObjC/messages-2.m test/Driver/noinline.c test/Index/remap-load.c test/Index/retain-comments-from-system-headers.c test/OpenMP/task_if_codegen.cpp test/Preprocessor/comment_save_macro.c Patch by: Mandeep Singh Grang (mgrang) Reviewers: rafael, ABataev, rengolin Projects: #clang-c Differential Revision: http://reviews.llvm.org/D19232 llvm-svn: 266843
* Warn if function or variable cannot be implicitly instantiatedSerge Pavlov2016-04-191-0/+1
| | | | | | | | | | | | With this patch compiler emits warning if it tries to make implicit instantiation of a template but cannot find the template definition. The warning can be suppressed by explicit instantiation declaration or by command line options -Wundefined-var-template and -Wundefined-func-template. The implementation follows the discussion of http://reviews.llvm.org/D12326. Differential Revision: http://reviews.llvm.org/D16396 llvm-svn: 266719
* Lit C++11 Compatibility Patch #8Charles Li2016-04-148-41/+247
| | | | | | 24 tests have been updated for C++11 compatibility. llvm-svn: 266387
* Lit C++11 Compatibility Patch #7Charles Li2016-04-135-49/+272
| | | | | | | 13 tests have been updated for C++11 compatibility. Differential Revision: http://reviews.llvm.org/D19068 llvm-svn: 266239
OpenPOWER on IntegriCloud