summaryrefslogtreecommitdiffstats
path: root/clang/test/SemaCXX
Commit message (Collapse)AuthorAgeFilesLines
...
* Revert rL362358 : PR42104: Support instantiations of lambdas that implicitly ↵Simon Pilgrim2019-06-031-24/+3
| | | | | | | | | | | | | | | | capture packs. Two changes: * Track odr-use via FunctionParmPackExprs to properly handle dependent odr-uses of packs in generic lambdas. * Do not instantiate implicit captures; instead, regenerate them by instantiating the body of the lambda. This is necessary to distinguish between cases where only one element of a pack is captured and cases where the entire pack is captured. ........ Fixes http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win buildbot failures llvm-svn: 362375
* PR42104: Support instantiations of lambdas that implicitly captureRichard Smith2019-06-031-3/+24
| | | | | | | | | | | | | | packs. Two changes: * Track odr-use via FunctionParmPackExprs to properly handle dependent odr-uses of packs in generic lambdas. * Do not instantiate implicit captures; instead, regenerate them by instantiating the body of the lambda. This is necessary to distinguish between cases where only one element of a pack is captured and cases where the entire pack is captured. llvm-svn: 362358
* [coroutines][PR41909] Don't build dependent coroutine statements for generic ↵Brian Gesiak2019-06-031-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | lambda Summary: https://bugs.llvm.org/show_bug.cgi?id=41909 describes an issue in which a generic lambda that takes a dependent argument `auto set` causes the template instantiation machinery for coroutine body statements to crash with an ICE. The issue is two-fold: 1. The paths taken by the template instantiator contain several asserts that the coroutine promise must not have a dependent type. 2. The template instantiator unconditionally builds corotuine statements that depend on the promise type, which cannot be dependent. To work around the issue, prevent the template instantiator from building dependent coroutine statements if the coroutine promise type is dependent. Since we only expect this to occur in the case of a generic lambda, limit the workaround behavior to just that case. Reviewers: GorNishanov, EricWF, lewissbaker, tks2103 Reviewed By: GorNishanov Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D62550 llvm-svn: 362348
* Suppress nothrow/Exception spec conflict warning when we dont know the ES.Erich Keane2019-05-311-0/+3
| | | | | | | In any situation where the Exception Spec isn't clear, suppress the warning to avoid false positives. llvm-svn: 362243
* Suppress nothrow/exception spec conflict warning when ES is parsed.Erich Keane2019-05-311-0/+13
| | | | | | | | | | | | | | The previously added warning ended up causing false positives when nothrow was used on member functions, where the exception specification wasn't yet parsed. So, throw() and noexcept(true) both were incorrectly warning. There doesn't seem to be a good way to force these to be parsed to identify which they are (and likely should not be), so suppress the warning. For now, unevaluated/uninstantiated are left as warnings as I am not creative enough to find a reproducer that causes a false positive for either. llvm-svn: 362236
* Fix for PR42089, regression from r362119Erich Keane2019-05-311-0/+9
| | | | | | | | | The implementation of the NoThrow ExceptionSpecificationType missed a switch statement for forming the diagnostic when an out-of-line member redeclaration misses the exception specification. This patch adds the correct case statement. llvm-svn: 362225
* PR39728: When completing a class, complete the destructor first.Richard Smith2019-05-311-0/+16
| | | | | | | | | We need to know whether the destructor is trivial in order to tell whether other parts of the class are valid (in particular, this affects whether the type is a literal type, which affects whether defaulted special members can be declared constexpr or are implicitly constexpr). llvm-svn: 362184
* Defer building 'this' captures until we have left the capturing regionRichard Smith2019-05-311-2/+4
| | | | | | | | | | and returned to the context in which 'this' should be captured. This means we now always mark 'this' referenced from the context in which it's actually referenced, rather than potentially from some context nested within that. llvm-svn: 362182
* Fix constexpr __builtin_*_overflow issue when unsigned->signed operand.Erich Keane2019-05-301-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | As reported here https://bugs.llvm.org/show_bug.cgi?id=42000, it was possible to get the constexpr version of __builtin_*_overflow to give the wrong answer. This was because when extending the operands to fit the largest type (so that the math could be done), the decision on whether to sign/zero extend the operands was based on the result signedness, not on the operands signedness. In the reported case, (unsigned char)255 - (int)100 needed to have each extended to the int in order to do the math. However, when extending the first operand to 'int', we incorrectly sign extended it instead of zero extending. Thus, the result didnt fit back into the unsigned char. The fix for this was simply to choose zero/sign extension based on the sign of the operand itself. Differential Revision: https://reviews.llvm.org/D62665 llvm-svn: 362157
* [c++2a] Fix assertion failure if we would walk over more than one levelRichard Smith2019-05-301-0/+10
| | | | | | | of derived-to-base conversion path when implicitly starting union subobject lifetimes in constant evaluation. llvm-svn: 362147
* Add Attribute NoThrow as an Exception Specifier TypeErich Keane2019-05-301-0/+55
| | | | | | | | | | | | | | | In response to https://bugs.llvm.org/show_bug.cgi?id=33235, it became clear that the current mechanism of hacking through checks for the exception specification of a function gets confused really quickly when there are alternate exception specifiers. This patch introcues EST_NoThrow, which is the equivilent of EST_noexcept when caused by EST_noThrow. The existing implementation is left in place to cover functions with no FunctionProtoType. Differential Revision: https://reviews.llvm.org/D62435 llvm-svn: 362119
* If capturing a variable fails, add a capture anyway (and mark itRichard Smith2019-05-281-2/+2
| | | | | | invalid) so that we can avoid repeated diagnostics for the same capture. llvm-svn: 361891
* Permit static local structured bindings to be named from arbitrary scopes ↵Richard Smith2019-05-251-2/+7
| | | | | | inside their declaring scope. llvm-svn: 361686
* Default arguments are potentially constant evaluated.Richard Smith2019-05-241-0/+18
| | | | | | | | We need to eagerly instantiate constexpr functions used in them even if the default argument is never actually used, because we might evaluate portions of it when performing semantic checks. llvm-svn: 361670
* Fix hang during constant evaluation of union assignment.Eric Fiselier2019-05-231-0/+8
| | | | | | | | | | HandleUnionActiveMemberChange forgot to walk over a nop implicit conversion node and got stuck in the process. As a cleanup I changed the declaration of `E` so it can't be accidentally accessed after the loop. llvm-svn: 361571
* Part of P1091R3: permit structured bindings to be declared 'static' andRichard Smith2019-05-222-1/+17
| | | | | | 'thread_local' in C++20. llvm-svn: 361424
* [c++20] P1330R0: permit simple-assignments that change the active memberRichard Smith2019-05-211-0/+101
| | | | | | of a union within constant expression evaluation. llvm-svn: 361329
* Rename identifiers to spell out analyze; NFC.Aaron Ballman2019-05-213-26/+26
| | | | llvm-svn: 361325
* Added a better diagnostic when using the delete operator with lambdasNicolas Lesser2019-05-191-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This adds a new error for missing parentheses around lambdas in delete operators. ``` int main() { delete []() { return new int(); }(); } ``` This will result in: ``` test.cpp:2:3: error: '[]' after delete interpreted as 'delete[]' delete []() { return new int(); }(); ^~~~~~~~~ test.cpp:2:9: note: add parentheses around the lambda delete []() { return new int(); }(); ^ ( ) ``` Reviewers: rsmith Reviewed By: rsmith Subscribers: riccibruno, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D36357 llvm-svn: 361119
* [c++20] P1327R1: Support for typeid applied to objects of polymorphicRichard Smith2019-05-171-0/+59
| | | | | | | | | class type in constant evaluation. This reinstates r360977, reverted in r360987, now that its rerequisite patch is reinstated and fixed. llvm-svn: 361067
* Attempt to fix test on Windows after r360998Nico Weber2019-05-171-1/+3
| | | | llvm-svn: 361054
* Fix crash if, during evaluation of __builtin_object_size, we try to loadRichard Smith2019-05-171-0/+7
| | | | | | through an invalid base. llvm-svn: 360998
* Refactor constant evaluation of typeid(T) to track a symbolic type_infoRichard Smith2019-05-172-1/+9
| | | | | | | | | | | | | | object rather than tracking the originating expression. This is groundwork for supporting polymorphic typeid expressions. (Note that this somewhat regresses our support for DR1968, but it turns out that that never actually worked anyway, at least in non-trivial cases.) This reinstates r360974, reverted in r360988, with a fix for a static_assert failure on 32-bit builds: force Type base class to have 8-byte alignment like the rest of Clang's AST nodes. llvm-svn: 360995
* Revert Refactor constant evaluation of typeid(T) to track a symbolic ↵Chris Bieneman2019-05-172-9/+1
| | | | | | | | type_info object rather than tracking the originating expression. This reverts r360974 (git commit 7ee4307bd4450022c3c8777f43a40cc4f0ccc009) llvm-svn: 360988
* Revert [c++20] P1327R1: Support for typeid applied to objects of polymorphic ↵Chris Bieneman2019-05-171-59/+0
| | | | | | | | class type in constant evaluation. This reverts r360977 (git commit f51dc8d2f98f4029247552bc45ef53628ab3b6b9) llvm-svn: 360987
* [c++20] P1327R1: Support for typeid applied to objects of polymorphicRichard Smith2019-05-171-0/+59
| | | | | | class type in constant evaluation. llvm-svn: 360977
* Refactor constant evaluation of typeid(T) to track a symbolic type_infoRichard Smith2019-05-172-1/+9
| | | | | | | | | | object rather than tracking the originating expression. This is groundwork for supporting polymorphic typeid expressions. (Note that this somewhat regresses our support for DR1968, but it turns out that that never actually worked anyway, at least in non-trivial cases.) llvm-svn: 360974
* Implement __builtin_LINE() et. al. to support source location capture.Eric Fiselier2019-05-162-0/+634
| | | | | | | | | | | | | | | | | Summary: This patch implements the source location builtins `__builtin_LINE(), `__builtin_FUNCTION()`, `__builtin_FILE()` and `__builtin_COLUMN()`. These builtins are needed to implement [`std::experimental::source_location`](https://rawgit.com/cplusplus/fundamentals-ts/v2/main.html#reflection.src_loc.creation). With the exception of `__builtin_COLUMN`, GCC also implements these builtins, and Clangs behavior is intended to match as closely as possible. Reviewers: rsmith, joerg, aaron.ballman, bogner, majnemer, shafik, martong Reviewed By: rsmith Subscribers: rnkovacs, loskutov, riccibruno, mgorny, kunitoki, alexr, majnemer, hfinkel, cfe-commits Differential Revision: https://reviews.llvm.org/D37035 llvm-svn: 360937
* [c++20] For P1327R1: support dynamic_cast in constant expressionRichard Smith2019-05-151-0/+52
| | | | | | evaluation. llvm-svn: 360806
* [c++20] P1064R0: Allow virtual function calls in constant expressionRichard Smith2019-05-133-4/+129
| | | | | | | | | | | | | 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
* Make more friendly with unions. Reviewed as https://reviews.llvm.org/D61858Marshall Clow2019-05-131-0/+15
| | | | llvm-svn: 360614
* Revert r360559 "[c++20] P1064R0: Allow virtual function calls in constant ↵Hans Wennborg2019-05-132-102/+0
| | | | | | | | | 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
* PR41854: Don't assert when constant-evaluating a member function call on an ↵Richard Smith2019-05-131-0/+8
| | | | | | invalid designator. llvm-svn: 360560
* [c++20] P1064R0: Allow virtual function calls in constant expressionRichard Smith2019-05-132-0/+102
| | | | | | evaluation. llvm-svn: 360559
* Reject attempts to call non-static member functions on objects outsideRichard Smith2019-05-121-10/+66
| | | | | | | | | | | | | | | | their lifetime in constant expressions. This is undefined behavior per [class.cdtor]p2. We continue to allow this for objects whose values are not visible within the constant evaluation, because there's no way we can tell whether the access is defined or not, existing code relies on the ability to make such calls, and every other compiler allows such calls. This reinstates r360499, reverted in r360531. llvm-svn: 360538
* Fix handling of objects under construction during constant expressionRichard Smith2019-05-121-0/+46
| | | | | | | | | | | | | evaluation. It's not enough to just track the LValueBase that we're evaluating, we need to also track the path to the objects whose constructors are running. This reinstates r360464 (reverted in r360531) with a workaround for an MSVC bug that previously caused the Windows bots to fail. llvm-svn: 360537
* Revert rL360499 and rL360464 from cfe/trunk:Simon Pilgrim2019-05-112-112/+10
| | | | | | | | | | | | | | | | | | | | | | | | Reject attempts to call non-static member functions on objects outside their lifetime in constant expressions. This is undefined behavior per [class.cdtor]p2. We continue to allow this for objects whose values are not visible within the constant evaluation, because there's no way we can tell whether the access is defined or not, existing code relies on the ability to make such calls, and every other compiler allows such calls. ........ Fix handling of objects under construction during constant expression evaluation. It's not enough to just track the LValueBase that we're evaluating, we need to also track the path to the objects whose constructors are running. ........ Fixes windows buildbots llvm-svn: 360531
* Reject attempts to call non-static member functions on objects outsideRichard Smith2019-05-111-10/+66
| | | | | | | | | | | | | | their lifetime in constant expressions. This is undefined behavior per [class.cdtor]p2. We continue to allow this for objects whose values are not visible within the constant evaluation, because there's no way we can tell whether the access is defined or not, existing code relies on the ability to make such calls, and every other compiler allows such calls. llvm-svn: 360499
* Fix handling of objects under construction during constant expressionRichard Smith2019-05-101-0/+46
| | | | | | | | | | evaluation. It's not enough to just track the LValueBase that we're evaluating, we need to also track the path to the objects whose constructors are running. llvm-svn: 360464
* [Sema] Mark array element destructors referenced during initializationErik Pilkington2019-05-101-3/+32
| | | | | | | | | | | | This fixes a crash where we would neglect to mark a destructor referenced for an __attribute__((no_destory)) array. The destructor is needed though, since if an exception is thrown we need to cleanup the elements. rdar://48462498 Differential revision: https://reviews.llvm.org/D61165 llvm-svn: 360446
* Assume `__cxa_allocate_exception` returns an under-aligned memory onAkira Hatanaka2019-05-101-0/+66
| | | | | | | | | | | | | | | | | | | | | Darwin if the version of libc++abi isn't new enough to include the fix in r319123 This patch resurrects r264998, which was committed to work around a bug in libc++abi that was causing _cxa_allocate_exception to return a memory that wasn't double-word aligned. http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20160328/154332.html In addition, this patch makes clang issue a warning if the type of the thrown object requires an alignment that is larger than the minimum guaranteed by the target C++ runtime. rdar://problem/49864414 Differential Revision: https://reviews.llvm.org/D61667 llvm-svn: 360404
* DR1872: don't allow any calls to virtual functions in constantRichard Smith2019-05-092-2/+2
| | | | | | | | evaluation. Not even in cases where we would not actually perform virtual dispatch. llvm-svn: 360370
* [c++20] Add support for explicit(bool), as described in P0892R2.Richard Smith2019-05-094-3/+761
| | | | | | | | Patch by Tyker! Differential Revision: https://reviews.llvm.org/D60934 llvm-svn: 360311
* [c++20] Implement P0846R0: allow (ADL-only) calls to template-ids whoseRichard Smith2019-05-096-11/+77
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* When typo-correcting a function name, consider correcting to a type nameRichard Smith2019-05-091-8/+8
| | | | | | for a function-style cast. llvm-svn: 360302
* Allow 'static' storage specifier on an out-of-line class member template ↵Aaron Ballman2019-05-081-0/+11
| | | | | | | | declaration in MSVCCompat mode. Patch by Soumi Manna. llvm-svn: 360250
* [Sema] Correct typos in return statements so the return types of 'auto' ↵Sam McCall2019-05-081-1/+12
| | | | | | | | | | | | | | | | | | | | | functions are always deduced. Summary: e.g. auto foo() { return no_such_thing; // Return value is a TypoExpr } using T = decltype(foo()); // Uh-oh, undeduced auto. Reviewers: rsmith Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D61649 llvm-svn: 360224
* Revert r359949 "[clang] adding explicit(bool) from c++2a"Hans Wennborg2019-05-064-746/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This caused Clang to start erroring on the following: struct S {   template <typename = int> explicit S(); }; struct T : S {}; struct U : T {   U(); }; U::U() {} $ clang -c /tmp/x.cc /tmp/x.cc:10:4: error: call to implicitly-deleted default constructor of 'T' U::U() {}    ^ /tmp/x.cc:5:12: note: default constructor of 'T' is implicitly deleted because base class 'S' has no default constructor struct T : S {};            ^ 1 error generated. See discussion on the cfe-commits email thread. This also reverts the follow-ups r359966 and r359968. > this patch adds support for the explicit bool specifier. > > Changes: > - The parsing for the explicit(bool) specifier was added in ParseDecl.cpp. > - The storage of the explicit specifier was changed. the explicit specifier was stored as a boolean value in the FunctionDeclBitfields and in the DeclSpec class. now it is stored as a PointerIntPair<Expr*, 2> with a flag and a potential expression in CXXConstructorDecl, CXXDeductionGuideDecl, CXXConversionDecl and in the DeclSpec class. > - Following the AST change, Serialization, ASTMatchers, ASTComparator and ASTPrinter were adapted. > - Template instantiation was adapted to instantiate the potential expressions of the explicit(bool) specifier When instantiating their associated declaration. > - The Add*Candidate functions were adapted, they now take a Boolean indicating if the context allowing explicit constructor or conversion function and this boolean is used to remove invalid overloads that required template instantiation to be detected. > - Test for Semantic and Serialization were added. > > This patch is not yet complete. I still need to check that interaction with CTAD and deduction guides is correct. and add more tests for AST operations. But I wanted first feedback. > Perhaps this patch should be spited in smaller patches, but making each patch testable as a standalone may be tricky. > > Patch by Tyker > > Differential Revision: https://reviews.llvm.org/D60934 llvm-svn: 360024
* P1286R2: Remove restriction that the exception specification of aRichard Smith2019-05-062-4/+21
| | | | | | defaulted special member matches the implicit exception specification. llvm-svn: 360011
* Use DiagRuntimeBehavior for -Wunsequenced to weed out false positivesRichard Smith2019-05-061-2/+2
| | | | | | | | | where either the modification or the other access is unreachable. This reverts r359984 (which reverted r359962). The bug in clang-tidy's test suite exposed by the original commit was fixed in r360009. llvm-svn: 360010
OpenPOWER on IntegriCloud