summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaExpr.cpp
Commit message (Collapse)AuthorAgeFilesLines
* PR45083: Mark statement expressions as being dependent if they appear inRichard Smith2020-03-121-4/+9
| | | | | | | | | | | | | | | | 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-12/+4
| | | | | | | | | 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-4/+12
| | | | | | | | | | 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] Check function constraints before deducing auto return typeSaar Raz2020-01-311-24/+24
| | | | | | | | | | A constrained function with an auto return type would have it's definition instantiated in order to deduce the auto return type before the constraints are checked. Move the constraints check after the return type deduction. (cherry picked from commit 980517b3530ffb7faa1a23fdc007d78f5b45ae3c)
* [Concepts] Add check for dependent RC when checking function constraintsSaar Raz2020-01-301-4/+2
| | | | | | | Do not attempt to check a dependent requires clause in a function constraint (may be triggered by, for example, DiagnoseUseOfDecl). (cherry picked from commit a424ef99e7b9821ec80564af3d3a8f091323a38c)
* [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-1/+12
| | | | | | | | | | 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)
* Add a FIXME and corresponding test coverage for some suspicious behaviorRichard Smith2020-01-101-0/+3
| | | | forming composite ObjC pointer types in comparisons.
* Remove redundant implicit cast creation.Richard Smith2020-01-101-2/+0
| | | | | FindCompositePointerType has already cast the operands to the composite type for us in the case where it succeeds.
* [Concepts] Function trailing requires clausesSaar Raz2020-01-091-1/+30
| | | | | | Function trailing requires clauses now parsed, supported in overload resolution and when calling, referencing and taking the address of functions or function templates. Differential Revision: https://reviews.llvm.org/D43357
* [NFC] Use isX86() instead of getArch()Jim Lin2020-01-071-2/+1
| | | | | | | | | | | | | | Summary: This is a clean up for https://reviews.llvm.org/D72247. Reviewers: MaskRay, craig.topper, jhenderson Reviewed By: MaskRay Subscribers: hiraditya, rupprecht, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D72320
* [c++20] P1959R0: Remove support for std::*_equality.Richard Smith2019-12-161-22/+35
|
* [c++20] Add deprecation warnings for the expression forms deprecated by P1120R0.Richard Smith2019-12-161-47/+100
| | | | | | | | | | | | | | | | | | | 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).
* Resolve exception specifications after marking the correspondingRichard Smith2019-12-151-21/+32
| | | | | | | | function as referenced, not before. No functionality change intended. This is groundwork for computing the exception specification of a defaulted comparison, for which we'd like to use the implicit body where possible.
* [c++20] Improve phrasing of diagnostic for missing #include <compare>.Richard Smith2019-12-131-2/+4
|
* Call objc_retainBlock before passing a block as a variadic argumentAkira Hatanaka2019-12-131-0/+3
| | | | | | | | | Copy the block to the heap before passing it to the callee in case the block escapes in the callee. rdar://problem/55683462 Differential Revision: https://reviews.llvm.org/D71431
* Correct gcc vector splat conversion from float to int-vectorErich Keane2019-12-131-0/+6
| | | | | | | | | | | | | | | | | | | | | | | In looking into some other code, I came across this issue where a float converted to a gcc integer vector via a splat causes it to miss the float-to-integral cast, which causes some REALLY strange codegen bugs. The AST looked like: `-ImplicitCastExpr <col:13> 'gcc_int_2':'__attribute__((__vector_size__(2 * sizeof(int)))) int' <VectorSplat> `-ImplicitCastExpr <col:13> 'float' <LValueToRValue> `-DeclRefExpr <col:13> 'float' lvalue ParmVar 0x556f16a5dc90 'f' 'float' Despite the type of the VectorSplat cast as printed, it ended up becoming a vector of float, which caused non-matching instructions. For example, IntVector + a float constant resulted in: add <2 x i32> %8, <2 x float> <float 3.000000e+00, float 3.000000e+00> This patch corrects the conversion so that the float is first converted to an integral, THEN splatted.
* Remove debugging printf and reformat code.Eric Christopher2019-12-101-4/+2
|
* [c++20] Return type deduction for defaulted three-way comparisons.Richard Smith2019-12-101-40/+14
|
* [c++20] Synthesis of defaulted comparison functions.Richard Smith2019-12-081-2/+7
| | | | | | Array members are not yet handled. In addition, defaulted comparisons can't yet find comparison operators by unqualified lookup (only by member lookup and ADL). These issues will be fixed in follow-on changes.
* [c++20] Determine whether a defaulted comparison should be deleted orRichard Smith2019-12-061-9/+4
| | | | constexpr.
* Add `QualType::hasAddressSpace`. NFC.Michael Liao2019-12-061-3/+3
| | | | | - Add that as a shorthand of <T>.getQualifiers().hasAddressSpace(). - Simplify related code.
* Reapply af57dbf12e54 "Add support for options -frounding-math, ↵Melanie Blower2019-12-051-0/+10
| | | | | | | | | | | | ftrapping-math, -ffp-model=, and -ffp-exception-behavior=" Patch was reverted because https://bugs.llvm.org/show_bug.cgi?id=44048 The original patch is modified to set the strictfp IR attribute explicitly in CodeGen instead of as a side effect of IRBuilder. In the 2nd attempt to reapply there was a windows lit test fail, the tests were fixed to use wildcard matching. Differential Revision: https://reviews.llvm.org/D62731
* Revert " Reapply af57dbf12e54 "Add support for options ↵Melanie Blower2019-12-041-10/+0
| | | | | | | -frounding-math, ftrapping-math, -ffp-model=, and -ffp-exception-behavior="" This reverts commit cdbed2dd856c14687efd741c2d8321686102acb8. Build break on Windows (lit fail)
* Reapply af57dbf12e54 "Add support for options -frounding-math, ↵Melanie Blower2019-12-041-0/+10
| | | | | | | | | | ftrapping-math, -ffp-model=, and -ffp-exception-behavior=" Patch was reverted because https://bugs.llvm.org/show_bug.cgi?id=44048 The original patch is modified to set the strictfp IR attribute explicitly in CodeGen instead of as a side effect of IRBuilder Differential Revision: https://reviews.llvm.org/D62731
* [Diagnostics] Warn for comparison with string literals expanded from macro ↵Dávid Bolvanský2019-11-241-40/+45
| | | | | | | | | | | | | | | | | | (PR44064) Summary: As noted in PR, we have a poor test coverage for this warning. I think macro support was just overlooked. GCC warns in these cases. Clang missed a real bug in the code I am working with, GCC caught it. Reviewers: aaron.ballman Reviewed By: aaron.ballman Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D70624
* Revert "[Sema] Use the canonical type in function isVector"Akira Hatanaka2019-11-221-1/+1
| | | | | This reverts commit a6150b48cea00ab31e9335cc73770327acc4cb3a. The commit broke a few neon CodeGen tests.
* [Sema] Use the canonical type in function isVectorAkira Hatanaka2019-11-221-1/+1
| | | | | | | This fixes an assertion in Sema::CreateBuiltinBinOp that fails when one of the vector operand's element type is a typedef of __fp16. rdar://problem/55983556
* [OpenCL] Fix address space for base method call (PR43145)Sven van Haastregt2019-11-211-0/+14
| | | | | | | | Clang was creating an UncheckedDerivedToBase ImplicitCastExpr that was also casting between address spaces. Insert an ImplicitCastExpr node for doing the address space conversion. Differential Revision: https://reviews.llvm.org/D69810
* [NFC] Refactor representation of materialized temporariesTyker2019-11-191-2/+2
| | | | | | | | | | | | | | | Summary: this patch refactor representation of materialized temporaries to prevent an issue raised by rsmith in https://reviews.llvm.org/D63640#inline-612718 Reviewers: rsmith, martong, shafik Reviewed By: rsmith Subscribers: thakis, sammccall, ilya-biryukov, rnkovacs, arphaman, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69360
* Revert "[NFC] Refactor representation of materialized temporaries"Nico Weber2019-11-171-2/+2
| | | | | | This reverts commit 08ea1ee2db5f9d6460fef1d79d0d1d1a5eb78982. It broke ./ClangdTests/FindExplicitReferencesTest.All on the bots, see comments on https://reviews.llvm.org/D69360
* [NFC] Refactor representation of materialized temporariesTyker2019-11-161-2/+2
| | | | | | | | | | | | | | | Summary: this patch refactor representation of materialized temporaries to prevent an issue raised by rsmith in https://reviews.llvm.org/D63640#inline-612718 Reviewers: rsmith, martong, shafik Reviewed By: rsmith Subscribers: rnkovacs, arphaman, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69360
* Avoid including Builtins.h in Preprocessor.hReid Kleckner2019-11-151-0/+1
| | | | | | Builtins are rarely if ever accessed via the Preprocessor. They are typically found on the ASTContext, so there should be no performance penalty to using a pointer indirection to store the builtin context.
* [Diagnostics] Fixed crash with non pointer type (PR43950)Dávid Bolvanský2019-11-091-1/+2
|
* [Diagnostics] Teach -Wnull-dereference about address_space attributeDávid Bolvanský2019-11-071-9/+14
| | | | | | | | | | | | | | | | | | | | | | Summary: Clang should not warn for: > test.c:2:12: warning: indirection of non-volatile null pointer will be deleted, > not trap [-Wnull-dereference] > return *(int __attribute__((address_space(256))) *) 0; > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Solves PR42292. Reviewers: aaron.ballman, rsmith Reviewed By: aaron.ballman Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69664
* Revert "[Sema] Suppress -Wchar-subscripts if the index is a literal char"Edward Jones2019-11-071-2/+1
| | | | This reverts commit 7adab7719e55e1b29bfd521dcc73f202139e8f41.
* [Sema] Suppress -Wchar-subscripts if the index is a literal charEdward Jones2019-11-071-1/+2
| | | | | | | | Assume that the user knows what they're doing if they provide a char literal as an array index. This more closely matches the behavior of GCC. Differential Revision: https://reviews.llvm.org/D58896
* Add -Wbitwise-conditional-parentheses to warn on mixing '|' and '&' with "?:"Richard Trieu2019-10-191-2/+11
| | | | | | | | | | | | | | | | | | | | Extend -Wparentheses to cover mixing bitwise-and and bitwise-or with the conditional operator. There's two main cases seen with this: unsigned bits1 = 0xf0 | cond ? 0x4 : 0x1; unsigned bits2 = cond1 ? 0xf0 : 0x10 | cond2 ? 0x5 : 0x2; // Intended order of evaluation: unsigned bits1 = 0xf0 | (cond ? 0x4 : 0x1); unsigned bits2 = (cond1 ? 0xf0 : 0x10) | (cond2 ? 0x5 : 0x2); // Actual order of evaluation: unsigned bits1 = (0xf0 | cond) ? 0x4 : 0x1; unsigned bits2 = cond1 ? 0xf0 : ((0x10 | cond2) ? 0x5 : 0x2); Differential Revision: https://reviews.llvm.org/D66043 llvm-svn: 375326
* [c++20] Add rewriting from comparison operators to <=> / ==.Richard Smith2019-10-191-0/+7
| | | | | | | | | | | | | | | | | This adds support for rewriting <, >, <=, and >= to a normal or reversed call to operator<=>, for rewriting != to a normal or reversed call to operator==, and for rewriting <=> and == to reversed forms of those same operators. Note that this is a breaking change for various C++17 code patterns, including some in use in LLVM. The most common patterns (where an operator== becomes ambiguous with a reversed form of itself) are still accepted under this patch, as an extension (with a warning). I'm hopeful that we can get the language rules fixed before C++20 ships, and the extension warning is aimed primarily at providing data to inform that decision. llvm-svn: 375306
* [ObjC] Diagnose implicit type coercion from ObjC 'Class' to objectJames Y Knight2019-10-171-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | pointer types. For example, in Objective-C mode, the initialization of 'x' in: ``` @implementation MyType + (void)someClassMethod { MyType *x = self; } @end ``` is correctly diagnosed with an incompatible-pointer-types warning, but in Objective-C++ mode, it is not diagnosed at all -- even though incompatible pointer conversions generally become an error in C++. This patch fixes that oversight, allowing implicit conversions involving Class only to/from unqualified-id, and between qualified and unqualified Class, where the protocols are compatible. Note that this does change some behaviors in Objective-C, as well, as shown by the modified tests. Of particular note is that assignment from from 'Class<MyProtocol>' to 'id<MyProtocol>' now warns. (Despite appearances, those are not compatible types. 'Class<MyProtocol>' is not expected to have instance methods defined by 'MyProtocol', while 'id<MyProtocol>' is.) Differential Revision: https://reviews.llvm.org/D67983 llvm-svn: 375125
* PR43080: Do not build context-sensitive expressions during name classification.Richard Smith2019-10-141-77/+100
| | | | | | | | | | | | | | | | | | | | | | | Summary: We don't know what context to use until the classification result is consumed by the parser, which could happen in a different semantic context. So don't build the expression that results from name classification until we get to that point and can handle it properly. This covers everything except C++ implicit class member access, which is a little awkward to handle properly in the face of the protected member access check. But it at least fixes all the currently-filed instances of PR43080. Reviewers: efriedma Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68896 llvm-svn: 374826
* [OPENMP]Fix codegen for private variably length vars in combinedAlexey Bataev2019-10-141-1/+19
| | | | | | | | | | | constructs. If OpenMP construct includes several capturing regions and the variable is declared as private, the length of the inner variable length array is not captured in outer captured regions, only in the innermost region. Patch fixes this bug. llvm-svn: 374787
* [sema] Revise `getCurrentMangleNumberContext` interface. NFC.Michael Liao2019-10-101-3/+4
| | | | | | | - Prefer returning mulitple values using a tuple instead of additional pointers/references. llvm-svn: 374274
* [c++20] P1152R4: warn on any simple-assignment to a volatile lvalueRichard Smith2019-10-091-8/+43
| | | | | | | | | | | | 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
* [c++20] Implement most of P1152R4.Richard Smith2019-10-091-0/+21
| | | | | | | | | | | | | | Diagnose some now-deprecated uses of volatile types: * as function parameter types and return types * as the type of a structured binding declaration * as the type of the lvalue operand of an increment / decrement / compound assignment operator This does not implement a check for the deprecation of simple assignments whose results are used; that check requires somewhat more complexity and will be addressed separately. llvm-svn: 374133
* [Diagnostics] Silence -Wsizeof-array-div for character buffersJames Clarke2019-10-081-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Character buffers are sometimes used to represent a pool of memory that contains non-character objects, due to them being synonymous with a stream of bytes on almost all modern architectures. Often, when interacting with hardware devices, byte buffers are therefore used as an intermediary and so we can end Character buffers are sometimes used to represent a pool of memory that contains non-character objects, due to them being synonymous with a stream of bytes on almost all modern architectures. Often, when interacting with hardware devices, byte buffers are therefore used as an intermediary and so we can end up generating lots of false-positives. Moreover, due to the ability of character pointers to alias non-character pointers, the strict aliasing violations that would generally be implied by the calculations caught by the warning (if the calculation itself is in fact correct) do not apply here, and so although the length calculation may be wrong, that is the only possible issue. Reviewers: rsmith, xbolva00, thakis Reviewed By: xbolva00, thakis Subscribers: thakis, lebedev.ri, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68526 llvm-svn: 374035
* [Diagnostics] Emit better -Wbool-operation's warning message if we known ↵David Bolvansky2019-10-071-4/+0
| | | | | | that the result is always true llvm-svn: 373973
* [Diagnostics] Highlight expr's source range for -Wbool-operationDavid Bolvansky2019-10-051-0/+1
| | | | | | Warning message looks better; and GCC adds it too. llvm-svn: 373828
* [Diagnostics] Use Expr::isKnownToHaveBooleanValue() to check bitwise ↵David Bolvansky2019-10-051-1/+1
| | | | | | | | negation of bool in languages without a bool type Thanks for this advice, Richard Trieu! llvm-svn: 373817
* Properly handle instantiation-dependent array bounds.Richard Smith2019-10-041-3/+5
| | | | | | | | | 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
OpenPOWER on IntegriCloud