summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaExprCXX.cpp
Commit message (Collapse)AuthorAgeFilesLines
* PR45083: Mark statement expressions as being dependent if they appear inRichard Smith2020-03-121-2/+3
| | | | | | | | | | | | | | | | a dependent context. This matches the GCC behavior. We track the enclosing template depth when determining whether a statement expression is within a dependent context; there doesn't appear to be any other reliable way to determine this. We previously assumed they were neither value- nor instantiation-dependent under any circumstances, which would lead to crashes and other misbehavior. (cherry picked from commit 5c845c1c50ac89a6f12557d1571678f3d1432478)
* Revert "PR45083: Mark statement expressions as being dependent if they ↵Hans Wennborg2020-03-121-3/+2
| | | | | | | | | appear in" This turned out to cause problems, and was reverted on master together with its follow-up change in 66addf8e803618758457e4d578c5084e322ca448. This reverts commit 3a843031a5ad83a00d2603f623881cb2b2bf719d.
* PR45083: Mark statement expressions as being dependent if they appear inRichard Smith2020-03-041-2/+3
| | | | | | | | | | dependent contexts. We previously assumed they were neither value- nor instantiation-dependent under any circumstances, which would lead to crashes and other misbehavior. (cherry picked from commit bdad0a1b79273733df9acc1be4e992fa5d70ec56)
* [Concepts] Transform constraints of non-template functions to ConstantEvaluatedSaar Raz2020-01-251-1/+2
| | | | | | | | | | We would previously try to evaluate atomic constraints of non-template functions as-is, and since they are now unevaluated at first, this would cause incorrect evaluation (bugs #44657, #44656). Substitute into atomic constraints of non-template functions as we would atomic constraints of template functions, in order to rebuild the expressions in a constant-evaluated context. (cherry picked from commit 713562f54858f10bf8998ee21ff2c7e7bad0d177)
* [Concepts] Requires ExpressionsSaar Raz2020-01-241-0/+213
| | | | | | | | | | Implement support for C++2a requires-expressions. Re-commit after compilation failure on some platforms due to alignment issues with PointerIntPair. Differential Revision: https://reviews.llvm.org/D50360 (cherry picked from commit a0f50d731639350c7a79f140f026c27a18215531)
* Remove redundant CXXScopeSpec from TemplateIdAnnotation.Richard Smith2020-01-241-2/+2
| | | | | | | | | | | | | | A TemplateIdAnnotation represents only a template-id, not a nested-name-specifier plus a template-id. Don't make a redundant copy of the CXXScopeSpec and store it on the template-id annotation. This slightly improves error recovery by more properly handling the case where we would form an invalid CXXScopeSpec while parsing a typename specifier, instead of accidentally putting the token stream into a broken "annot_template_id with a scope specifier, but with no preceding annot_cxxscope token" state. (cherry picked from commit a42fd84cff265b7e9faa3fe42885ee171393e4db)
* Implement VectorType conditional operator GNU extension.Erich Keane2020-01-131-15/+147
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | GCC supports the conditional operator on VectorTypes that acts as a 'select' in C++ mode. This patch implements the support. Types are converted as closely to GCC's behavior as possible, though in a few places consistency with our existing vector type support was preferred. Note that this implementation is different from the OpenCL version in a number of ways, so it unfortunately required a different implementation. First, the SEMA rules and promotion rules are significantly different. Secondly, GCC implements COND[i] != 0 ? LHS[i] : RHS[i] (where i is in the range 0- VectorSize, for each element). In OpenCL, the condition is COND[i] < 0 ? LHS[i]: RHS[i]. In the process of implementing this, it was also required to make the expression COND ? LHS : RHS type dependent if COND is type dependent, since the type is now dependent on the condition. For example: T ? 1 : 2; Is not typically type dependent, since the result can be deduced from the operands. HOWEVER, if T is a VectorType now, it could change this to a 'select' (basically a swizzle with a non-constant mask) with the 1 and 2 being promoted to vectors themselves. While this is a change, it is NOT a standards incompatible change. Based on my (and D. Gregor's, at the time of writing the code) reading of the standard, the expression is supposed to be type dependent if ANY sub-expression is type dependent. Differential Revision: https://reviews.llvm.org/D71463
* Clean up and slightly generalize implementation of composite pointerRichard Smith2020-01-101-126/+212
| | | | | | | | | | | type computation, in preparation for P0388R4, which adds another few cases here. We now properly handle forming multi-level composite pointer types involving nested Objective-C pointer types (as is consistent with including them as part of the notion of 'similar types' on which this rule is based). We no longer lose non-CVR qualifiers on nested pointer types.
* CWG2352: Allow qualification conversions during reference binding.Richard Smith2020-01-091-1/+5
| | | | | | | | | | | | | | | | | | | | | | The language wording change forgot to update overload resolution to rank implicit conversion sequences based on qualification conversions in reference bindings. The anticipated resolution for that oversight is implemented here -- we order candidates based on qualification conversion, not only on top-level cv-qualifiers, including ranking reference bindings against non-reference bindings if they differ in non-top-level qualification conversions. For OpenCL/C++, this allows reference binding between pointers with differing (nested) address spaces. This makes the behavior of reference binding consistent with that of implicit pointer conversions, as is the purpose of this change, but that pre-existing behavior for pointer conversions is itself probably not correct. In any case, it's now consistently the same behavior and implemented in only one place. This reinstates commit de21704ba96fa80d3e9402f12c6505917a3885f4, reverted in commit d8018233d1ea4234de68d5b4593abd773db79484, with workarounds for some overload resolution ordering problems introduced by CWG2352.
* Revert "CWG2352: Allow qualification conversions during reference binding."David Blaikie2019-12-271-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit de21704ba96fa80d3e9402f12c6505917a3885f4. Regressed/causes this to error due to ambiguity: void f(const int * const &); void f(int *); int main() { int * x; f(x); } (in case it's important - the original case where this turned up was a member function overload in a class template with, essentially: f(const T1&) f(T2*) (where T1 == X const *, T2 == X)) It's not super clear to me if this ^ is expected behavior, in which case I'm sorry about the revert & happy to look into ways to fix the original code.
* CWG2352: Allow qualification conversions during reference binding.Richard Smith2019-12-191-0/+2
| | | | | | | | | | | | | | | The language wording change forgot to update overload resolution to rank implicit conversion sequences based on qualification conversions in reference bindings. The anticipated resolution for that oversight is implemented here -- we order candidates based on qualification conversion, not only on top-level cv-qualifiers. For OpenCL/C++, this allows reference binding between pointers with differing (nested) address spaces. This makes the behavior of reference binding consistent with that of implicit pointer conversions, as is the purpose of this change, but that pre-existing behavior for pointer conversions is itself probably not correct. In any case, it's now consistently the same behavior and implemented in only one place.
* Refactor CompareReferenceRelationship and its callers in preparation forRichard Smith2019-12-181-12/+12
| | | | | | | | | | | | | | implementing the resolution of CWG2352. No functionality change, except that we now convert the referent of a reference binding to the underlying type of the reference in more cases; we used to happen to preserve the type sugar from the referent if the only type change was in the cv-qualifiers. This exposed a bug in how we generate code for trivial assignment operators: if the type sugar (particularly the may_alias attribute) got lost during reference binding, we'd use the "wrong" TBAA information for the load during the assignment.
* [c++20] Add deprecation warnings for the expression forms deprecated by P1120R0.Richard Smith2019-12-161-1/+2
| | | | | | | | | | | | | | | | | | | This covers: * usual arithmetic conversions (comparisons, arithmetic, conditionals) between different enumeration types * usual arithmetic conversions between enums and floating-point types * comparisons between two operands of array type The deprecation warnings are on-by-default (in C++20 compilations); it seems likely that these forms will become ill-formed in C++23, so warning on them now by default seems wise. For the first two bullets, off-by-default warnings were also added for all the cases where we didn't already have warnings (covering language modes prior to C++20). These warnings are in subgroups of the existing -Wenum-conversion (except that the first case is not warned on if either enumeration type is anonymous, consistent with our existing -Wenum-conversion warnings).
* [OpenCL] Fix address space for implicit conversion (PR43145)Sven van Haastregt2019-12-021-3/+20
| | | | | | | | | | Clang was creating a DerivedToBase ImplicitCastExpr that was also casting between address spaces as part of the second step in the standard conversion sequence. Defer the address space conversion to the third step in the sequence instead, such that we get a separate ImplicitCastExpr for the address space conversion. Differential Revision: https://reviews.llvm.org/D70605
* [MS] Don't reference deleted copy ctors from catchable typesReid Kleckner2019-10-301-1/+1
| | | | | | | | | | | When throwing objects with deleted copy constructors, the copy ctor field of the catchable type should remain null and the mangle name changes. This already worked in simple cases, but in cases involving non-trivial subobjects, sometimes LookupCopyingConstructor could return a non-null but deleted constructor decl. Skip those and don't reference them. Fixes PR43680
* [Sema][Typo Correction] Fix another infinite loop on ambiguityDavid Goldman2019-10-251-2/+3
| | | | | | | | | | | See also: D67515 - For the given call expression we would end up repeatedly trying to transform the same expression over and over again - Fix is to keep the old TransformCache when checking for ambiguity Differential Revision: https://reviews.llvm.org/D69060
* When diagnosing an ambiguity, only note the candidates that contributeRichard Smith2019-10-241-2/+2
| | | | to the ambiguity, rather than noting all viable candidates.
* Sema: Create a no-op implicit cast for lvalue function conversions.Peter Collingbourne2019-10-191-8/+9
| | | | | | | | | | This fixes an assertion failure in the case where an implicit conversion for a function call involves an lvalue function conversion, and makes the AST for initializations involving implicit lvalue function conversions more accurate. Differential Revision: https://reviews.llvm.org/D66437 llvm-svn: 375313
* SemaExprCXX - silence static analyzer getAs<> null dereference warnings. NFCI.Simon Pilgrim2019-10-171-3/+3
| | | | | | The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<> directly and if not assert will fire for us. llvm-svn: 375101
* Suppress false-positive -Wdeprecated-volatile warning from ↵Richard Smith2019-10-111-1/+7
| | | | | | __is_*_assignable(volatile T&, U). llvm-svn: 374580
* [c++20] P1152R4: warn on any simple-assignment to a volatile lvalueRichard Smith2019-10-091-7/+33
| | | | | | | | | | | | whose value is not ignored. We don't warn on all the cases that are deprecated: specifically, we choose to not warn for now if there are parentheses around the assignment but its value is not actually used. This seems like a more defensible rule, particularly for cases like sizeof(v = a), where the parens are part of the operand rather than the sizeof syntax. llvm-svn: 374135
* Properly handle instantiation-dependent array bounds.Richard Smith2019-10-041-3/+4
| | | | | | | | | We previously failed to treat an array with an instantiation-dependent but not value-dependent bound as being an instantiation-dependent type. We now track the array bound expression as part of a constant array type if it's an instantiation-dependent expression. llvm-svn: 373685
* Check for qualified function types after substituting into the operandRichard Smith2019-10-031-0/+3
| | | | | | | | | | of 'typeid'. This is a rare place where it's valid for a function type to be substituted but not valid for a qualified function type to be substituted, so needs a special check. llvm-svn: 373648
* Silence static analyzer getAs<RecordType> null dereference warnings. NFCI.Simon Pilgrim2019-10-031-2/+2
| | | | | | The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<RecordType> directly and if not assert will fire for us. llvm-svn: 373584
* Fix __is_signed builtinZoe Carver2019-09-231-1/+3
| | | | | | | | | | | | | | Summary: This patch fixes the __is_signed builtin type trait to work with floating point types and enums. Now, the builtin will return true if it is passed a floating point type and false for an enum type. Reviewers: EricWF, rsmith, erichkeane, craig.topper, efriedma Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D67897 llvm-svn: 372621
* [Sema][Typo Correction] Fix potential infite loop on ambiguity checksDavid Goldman2019-09-131-0/+4
| | | | | | | | | | | | | | | | | | | | | | Summary: This fixes a bug introduced in D62648, where Clang could infinite loop if it became stuck on a single TypoCorrection when it was supposed to be testing ambiguous corrections. Although not a common case, it could happen if there are multiple possible corrections with the same edit distance. The fix is simply to wipe the TypoExpr from the `TransformCache` so that the call to `TransformTypoExpr` doesn't use the `CachedEntry`. Reviewers: rsmith Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D67515 llvm-svn: 371859
* [Sema][Typo] Fix assertion failure for expressions with multiple typosDavid Goldman2019-08-201-42/+152
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: As Typo Resolution can create new TypoExprs while resolving typos, it is necessary to recurse through the expression to search for more typos. This should fix the assertion failure in `clang::Sema::~Sema()`: `DelayedTypos.empty() && "Uncorrected typos!"` Notes: - In case some TypoExprs are created but thrown away, Sema now has a Vector that is used to keep track of newly created typos. - For expressions with multiple typos, we only give suggestions if we are able to resolve all typos in the expression - This patch is similar to D37521 except that it does not eagerly commit to a correction for the first typo in the expression. Instead, it will search for corrections which fix all of the typos in the expression. Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D62648 llvm-svn: 369427
* Fix handling of class member access into a vector type.Richard Smith2019-08-141-5/+1
| | | | | | | | | | | | | | | | | | | | | | When handling a member access into a non-class, non-ObjC-object type, we would perform a lookup into the surrounding scope as if for an unqualified lookup. If the member access was followed by a '<' and this lookup (or the typo-correction for it) found a template name, we'd treat the member access as naming that template. Now we treat such accesses as never naming a template if the type of the object expression is of vector type, so that vector component accesses are never misinterpreted as naming something else. This is not entirely correct, since it is in fact valid to name a template from the enclosing scope in this context, when invoking a pseudo-destructor for the vector type via an alias template, but that's very much a corner case, and this change leaves that case only as broken as the corresponding case for Objective-C types is. This incidentally adds support for dr2292, which permits a 'template' keyword at the start of a member access naming a pseudo-destructor. llvm-svn: 368940
* [clang][NFCI] Fix random typosJan Korous2019-07-231-1/+1
| | | | llvm-svn: 366823
* [OpenCL] Update comments/diagnostics to refer to C++ for OpenCLAnastasia Stulova2019-07-181-3/+3
| | | | | | | | | Clang doesn't implement OpenCL C++, change the comments to reflect that. Differential Revision: https://reviews.llvm.org/D64867 llvm-svn: 366421
* [OpenCL][Sema] Minor refactoring and constraint checkingMarco Antognini2019-07-171-9/+4
| | | | | | | | | | | | | | Summary: Simplify code a bit and add assertion to address post-landing comments from D64083. Subscribers: yaxunl, Anastasia, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64804 llvm-svn: 366306
* Fix parameter name comments using clang-tidy. NFC.Rui Ueyama2019-07-161-1/+1
| | | | | | | | | | | | | | | | | | | | | This patch applies clang-tidy's bugprone-argument-comment tool to LLVM, clang and lld source trees. Here is how I created this patch: $ git clone https://github.com/llvm/llvm-project.git $ cd llvm-project $ mkdir build $ cd build $ cmake -GNinja -DCMAKE_BUILD_TYPE=Debug \ -DLLVM_ENABLE_PROJECTS='clang;lld;clang-tools-extra' \ -DCMAKE_EXPORT_COMPILE_COMMANDS=On -DLLVM_ENABLE_LLD=On \ -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ ../llvm $ ninja $ parallel clang-tidy -checks='-*,bugprone-argument-comment' \ -config='{CheckOptions: [{key: StrictMode, value: 1}]}' -fix \ ::: ../llvm/lib/**/*.{cpp,h} ../clang/lib/**/*.{cpp,h} ../lld/**/*.{cpp,h} llvm-svn: 366177
* [OpenCL][Sema] Improve address space support for blocksMarco Antognini2019-07-091-1/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch ensures that the following code is compiled identically with -cl-std=CL2.0 and -fblocks -cl-std=c++. kernel void test(void) { void (^const block_A)(void) = ^{ return; }; } A new test is not added because cl20-device-side-enqueue.cl will cover this once blocks are further improved for C++ for OpenCL. The changes to Sema::PerformImplicitConversion are based on the parts of Sema::CheckAssignmentConstraints on block pointer conversions. Reviewers: rjmccall, Anastasia Subscribers: yaxunl, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64083 llvm-svn: 365500
* Revert [Sema] Resolve placeholder types before type deduction to silence ↵Reid Kleckner2019-07-081-8/+0
| | | | | | | | | | | | | | | | | | | | | | spurious `-Warc-repeated-use-of-weak` warnings This reverts r365382 (git commit 8b1becf2e31d9170ee356a19c7b6ea991d3a520f) Appears to regress this semi-reduced fragment of valid code from windows SDK headers: #define InterlockedIncrement64 _InterlockedIncrement64 extern "C" __int64 InterlockedIncrement64(__int64 volatile *Addend); #pragma intrinsic(_InterlockedIncrement64) unsigned __int64 InterlockedIncrement(unsigned __int64 volatile *Addend) { return (unsigned __int64)(InterlockedIncrement64)((volatile __int64 *)Addend); } Found on a buildbot here, but no mail was sent due to it already being red: http://lab.llvm.org:8011/builders/sanitizer-windows/builds/48067 llvm-svn: 365393
* [Sema] Resolve placeholder types before type deduction to silenceAkira Hatanaka2019-07-081-0/+8
| | | | | | | | | | | | | | | | | | spurious `-Warc-repeated-use-of-weak` warnings The spurious -Warc-repeated-use-of-weak warnings are issued when an initializer expression uses a weak ObjC pointer. My first attempt to silence the warnings (r350917) caused clang to reject code that is legal in C++17. The patch is based on the feedback I received from Richard when the patch was reverted. http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20190422/268945.html http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20190422/268943.html Differential Revision: https://reviews.llvm.org/D62645 llvm-svn: 365382
* [OpenCL] Improve diagnostic for placement newSven van Haastregt2019-06-261-1/+5
| | | | | | | | | | | | | Without an explicit declaration for placement new, clang would reject uses of placement new with "'default new' is not supported in OpenCL C++". This may mislead users into thinking that placement new is not supported, see e.g. PR42060. Clarify that placement new requires an explicit declaration. Differential Revision: https://reviews.llvm.org/D63561 llvm-svn: 364423
* [clang] Don't segfault on incorrect using directive (PR41400)Gauthier Harnisch2019-06-141-1/+1
| | | | | | | | | | | | | | | | | | | Summary: this is a bugfixe for [[ https://bugs.llvm.org/show_bug.cgi?id=41400 | PR41400 ]] added nullptr check at the relevent place and test Reviewers: rsmith, riccibruno Reviewed By: rsmith Subscribers: jkooker, jkorous, riccibruno, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D60523 llvm-svn: 363360
* For DR712: store on a DeclRefExpr whether it constitutes an odr-use.Richard Smith2019-06-111-1/+1
| | | | | | | Begin restructuring to support the forms of non-odr-use reference permitted by DR712. llvm-svn: 363086
* Factor out duplicated code building a MemberExpr and marking itRichard Smith2019-06-061-9/+6
| | | | | | | | referenced. This reinstates r362563, reverted in r362597. llvm-svn: 362757
* Convert MemberExpr creation and serialization to work the same way asRichard Smith2019-06-061-3/+6
| | | | | | | | | | most / all other Expr subclasses. This reinstates r362551, reverted in r362597, with a fix to a bug that caused MemberExprs to sometimes have a null FoundDecl after a round-trip through an AST file. llvm-svn: 362756
* Revert "Factor out duplicated code building a MemberExpr and marking it" and ↵Benjamin Kramer2019-06-051-6/+6
| | | | | | | | "Convert MemberExpr creation and serialization to work the same way as" This reverts commits r362551 and r362563. Crashes during modules selfhost. llvm-svn: 362597
* Factor out duplicated code building a MemberExpr and marking itRichard Smith2019-06-051-9/+6
| | | | | | referenced. llvm-svn: 362563
* Convert MemberExpr creation and serialization to work the same way asRichard Smith2019-06-041-3/+6
| | | | | | most / all other Expr subclasses. llvm-svn: 362551
* Factor out repeated code to build a DeclRefExpr and mark it referenced.Richard Smith2019-06-041-6/+3
| | | | llvm-svn: 362537
* PR42104: Support instantiations of lambdas that implicitly captureRichard Smith2019-06-041-8/+3
| | | | | | | | | | | | | | | | | 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. This reinstates r362358 (reverted in r362375) with a fix for an uninitialized variable use in UpdateMarkingForLValueToRValue. llvm-svn: 362531
* Revert rL362358 : PR42104: Support instantiations of lambdas that implicitly ↵Simon Pilgrim2019-06-031-3/+8
| | | | | | | | | | | | | | | | 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-8/+3
| | | | | | | | | | | | | | 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
* Defer building 'this' captures until we have left the capturing regionRichard Smith2019-05-311-34/+1
| | | | | | | | | | 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
* Add Attribute NoThrow as an Exception Specifier TypeErich Keane2019-05-301-0/+3
| | | | | | | | | | | | | | | 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
* Defer creating fields for captures until we finish building theRichard Smith2019-05-281-38/+25
| | | | | | | | | | | | | | | capturing expression or statement. No functionality change yet. The intent is that we will also delay building the initialization expression until the enclosing context, so that: a) we build the initialization expression in the right context, and b) we can elide captures that are not odr-used, as suggested by P0588R1. This also consolidates some duplicated code building capture fields into a single place. llvm-svn: 361893
OpenPOWER on IntegriCloud