summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaExpr.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [Sema] Add warning for unused lambda capturesMalcolm Parsons2017-01-131-1/+3
| | | | | | | | | | | | | | | Summary: Warn when a lambda explicitly captures something that is not used in its body. The warning is part of -Wunused and can be enabled with -Wunused-lambda-capture. Reviewers: rsmith, arphaman, jbcoe, aaron.ballman Subscribers: Quuxplusone, arphaman, cfe-commits Differential Revision: https://reviews.llvm.org/D28467 llvm-svn: 291905
* [cxx1z-constexpr-lambda] [NFC] Add a FIXME to reinstate certain restrictions ↵Faisal Vali2017-01-091-0/+6
| | | | | | | | | | | | on constexpr lambdas from appearing within function-signatures (CWG1607) For further background, see Richard's comments: http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20170109/181998.html A patch to fix this is being worked on. Thanks! llvm-svn: 291439
* Add the diagnose_if attribute to clang.George Burgess IV2017-01-091-26/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `diagnose_if` can be used to have clang emit either warnings or errors for function calls that meet user-specified conditions. For example: ``` constexpr int foo(int a) __attribute__((diagnose_if(a > 10, "configurations with a > 10 are " "expensive.", "warning"))); int f1 = foo(9); int f2 = foo(10); // warning: configuration with a > 10 are expensive. int f3 = foo(f2); ``` It currently only emits diagnostics in cases where the condition is guaranteed to always be true. So, the following code will emit no warnings: ``` constexpr int bar(int a) { foo(a); return 0; } constexpr int i = bar(10); ``` We hope to support optionally emitting diagnostics for cases like that (and emitting runtime checks) in the future. Release notes will appear shortly. :) Differential Revision: https://reviews.llvm.org/D27424 llvm-svn: 291418
* [cxx1z-constexpr-lambda] Implement constant evaluation of non-capturing ↵Faisal Vali2017-01-091-2/+4
| | | | | | | | | | | | | | | lambda expressions. Add a visitor for lambda expressions to RecordExprEvaluator in ExprConstant.cpp that creates an empty APValue of Struct type to represent the closure object. Additionally, add a LambdaExpr visitor to the TemporaryExprEvaluator that forwards constant evaluation of immediately-called-lambda-expressions to the one in RecordExprEvaluator through VisitConstructExpr. This patch supports: constexpr auto ID = [] (auto a) { return a; }; static_assert(ID(3.14) == 3.14); static_assert([](auto a) { return a + 1; }(10) == 11); Lambda captures are still not supported for constexpr lambdas. llvm-svn: 291416
* PR23135: Don't instantiate constexpr functions referenced in unevaluated ↵Richard Smith2017-01-071-51/+63
| | | | | | | | | | | | | | | | | | | | | operands where possible. This implements something like the current direction of DR1581: we use a narrow syntactic check to determine the set of places where a constant expression could be evaluated, and only instantiate a constexpr function or variable if it's referenced in one of those contexts, or is odr-used. It's not yet clear whether this is the right set of syntactic locations; we currently consider all contexts within templates that would result in odr-uses after instantiation, and contexts within list-initialization (narrowing conversions take another victim...), as requiring instantiation. We could in principle restrict the former cases more (only const integral / reference variable initializers, and contexts in which a constant expression is required, perhaps). However, this is sufficient to allow us to accept libstdc++ code, which relies on GCC's behavior (which appears to be somewhat similar to this approach). llvm-svn: 291318
* Revisit PR10177: don't instantiate a variable if it's only referenced in aRichard Smith2017-01-061-63/+46
| | | | | | | | | | | | | | dependent context and can't be used in a constant expression. Per C++ [temp.inst]p2, "the instantiation of a static data member does not occur unless the static data member is used in a way that requires the definition to exist". This doesn't /quite/ match that, as we still instantiate static data members that are usable in constant expressions even if the use doesn't require a definition. A followup patch will fix that for both variables and functions. llvm-svn: 291295
* Bail out if we try to build a DeclRefExpr naming an invalid declaration.Richard Smith2017-01-041-0/+3
| | | | | | | | | | | Most code paths would already bail out in this case, but certain paths, particularly overload resolution and typo correction, would not. Carrying on with an invalid declaration could in some cases result in crashes due to downstream code relying on declaration invariants that are not necessarily met for invalid declarations, and in other cases just resulted in undesirable follow-on diagnostics. llvm-svn: 291030
* Fix problems in "[OpenCL] Enabling the usage of CLK_NULL_QUEUE as compare ↵Egor Churaev2016-12-231-0/+12
| | | | | | | | | | | | | | operand." Summary: Fixed warnings in commit: https://reviews.llvm.org/rL290171 Reviewers: djasper, Anastasia Subscribers: yaxunl, cfe-commits, bader Differential Revision: https://reviews.llvm.org/D27981 llvm-svn: 290431
* Revert "[OpenCL] Enabling the usage of CLK_NULL_QUEUE as compare operand."Daniel Jasper2016-12-201-12/+0
| | | | | | | | | | This reverts commit r290171. It triggers a bunch of warnings, because the new enumerator isn't handled in all switches. We want a warning-free build. Replied on the commit with more details. llvm-svn: 290173
* [OpenCL] Enabling the usage of CLK_NULL_QUEUE as compare operand.Egor Churaev2016-12-201-0/+12
| | | | | | | | | | | | Summary: Enabling the compression of CLK_NULL_QUEUE to variable of type queue_t. Reviewers: Anastasia Subscribers: cfe-commits, yaxunl, bader Differential Revision: https://reviews.llvm.org/D27569 llvm-svn: 290171
* Recommit r289979 [OpenCL] Allow disabling types and declarations associated ↵Yaxun Liu2016-12-181-5/+8
| | | | | | | | with extensions Fixed undefined behavior due to cast integer to bool in initializer list. llvm-svn: 290056
* Revert r289979 due to regressionsYaxun Liu2016-12-161-8/+5
| | | | llvm-svn: 289991
* [OpenCL] Allow disabling types and declarations associated with extensionsYaxun Liu2016-12-161-5/+8
| | | | | | | | | | | | | | | | | | Added a map to associate types and declarations with extensions. Refactored existing diagnostic for disabled types associated with extensions and extended it to declarations for generic situation. Fixed some bugs for types associated with extensions. Allow users to use pragma to declare types and functions for supported extensions, e.g. #pragma OPENCL EXTENSION the_new_extension_name : begin // declare types and functions associated with the extension here #pragma OPENCL EXTENSION the_new_extension_name : end Differential Revision: https://reviews.llvm.org/D21698 llvm-svn: 289979
* Replace APFloatBase static fltSemantics data members with getter functionsStephan Bergmann2016-12-141-1/+1
| | | | | | | | | | | | | At least the plugin used by the LibreOffice build (<https://wiki.documentfoundation.org/Development/Clang_plugins>) indirectly uses those members (through inline functions in LLVM/Clang include files in turn using them), but they are not exported by utils/extract_symbols.py on Windows, and accessing data across DLL/EXE boundaries on Windows is generally problematic. Differential Revision: https://reviews.llvm.org/D26671 llvm-svn: 289647
* Improve handling of floating point literals in OpenCL to only use double ↵Neil Hickey2016-12-131-5/+16
| | | | | | | | | | | | | | precision if the target supports fp64. This change makes sure single-precision floating point types are used if the cl_fp64 extension is not supported by the target. Also removed the check to see whether the OpenCL version is >= 1.2, as this has been incorporated into the extension setting code. Differential Revision: https://reviews.llvm.org/D24235 llvm-svn: 289544
* DR1213: element access on an array xvalue or prvalue produces an xvalue. In theRichard Smith2016-12-051-5/+33
| | | | | | | | | | | | | | latter case, a temporary array object is materialized, and can be lifetime-extended by binding a reference to the member access. Likewise, in an array-to-pointer decay, an rvalue array is materialized before being converted into a pointer. This caused IR generation to stop treating file-scope array compound literals as having static storage duration in some cases in C++; that has been rectified by modeling such a compound literal as an lvalue. This also improves clang's compatibility with GCC for those cases. llvm-svn: 288654
* DR616, and part of P0135R1: member access (or pointer-to-member access) on aRichard Smith2016-12-031-3/+3
| | | | | | | temporary produces an xvalue, not a prvalue. Support this by materializing the temporary prior to performing the member access. llvm-svn: 288563
* More diagnostic name fixups: w_ -> warn_, warning_ -> warn_, not_ -> note_.Richard Smith2016-12-021-1/+1
| | | | | | In passing, add a warning group for "ignored qualifier in inline assembly" warnings. llvm-svn: 288548
* Mass-rename the handful of error_* diagnostics to err_*.Richard Smith2016-12-021-5/+5
| | | | llvm-svn: 288545
* Remove C++ default arg side table for MS ABI ctor closuresReid Kleckner2016-11-231-11/+16
| | | | | | | | | | | | | | | | | | | Summary: We don't need a side table in ASTContext to hold CXXDefaultArgExprs. The important part of building the CXXDefaultArgExprs was to ODR use the default argument expressions, not to make AST nodes. Refactor the code to only check the default argument, and remove the side table in ASTContext which wasn't being serialized. Fixes PR31121 Reviewers: thakis, rsmith, majnemer Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D27007 llvm-svn: 287774
* [Sema] Don't allow applying address-of operator to a call to a functionAkira Hatanaka2016-11-191-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | with __unknown_anytype return type. When the following code is compiled, Sema infers that the type of __unknown_anytype is double: extern __unknown_anytype func(); double *d = (double*)&func(); This triggers an assert in CodeGenFunction::EmitCallExprLValue because it doesn't expect to see a call to a function with a non-reference scalar return type. This commit prevents the assert by making VisitUnaryAddrOf error out if the address-of operator is applied to a call to a function with __unknown_anytype return type. rdar://problem/20287610 Differential revision: https://reviews.llvm.org/D26808 llvm-svn: 287410
* Revert "Improve handling of floating point literals in OpenCL to only use ↵Renato Golin2016-11-141-22/+7
| | | | | | | | double precision if the target supports fp64." This reverts commit r286815, as it broke all ARM and AArch64 bots. llvm-svn: 286818
* Improve handling of floating point literals in OpenCL to only use double ↵Neil Hickey2016-11-141-7/+22
| | | | | | | | | | | | | | precision if the target supports fp64. This change makes sure single-precision floating point types are used if the cl_fp64 extension is not supported by the target. Also removed the check to see whether the OpenCL version is >= 1.2, as this has been incorporated into the extension setting code. Differential Revision: https://reviews.llvm.org/D24235 llvm-svn: 286815
* Fix for PR28523: unexpected compilation error.Alexey Bataev2016-11-111-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Clang emits error message for the following code: ``` template <class F> void parallel_loop(F &&f) { f(0); } int main() { int x; parallel_loop([&](auto y) { { x = y; }; }); } ``` $ clang++ --std=gnu++14 clang_test.cc -o clang_test clang_test.cc:9:7: error: reference to local variable 'x' declared in enclosing function 'main' x = y; ^ clang_test.cc:2:48: note: in instantiation of function template specialization 'main()::(anonymous class)::operator()<int>' requested here template <class F> void parallel_loop(F &&f) { f(0); } ^ clang_test.cc:6:3: note: in instantiation of function template specialization 'parallel_loop<(lambda at clang_test.cc:6:17)>' requested here parallel_loop([&](auto y) { ^ clang_test.cc:5:7: note: 'x' declared here int x; ^ 1 error generated. Patch fixes this issue. llvm-svn: 286584
* [Sema] Remove a dead assignment, NFC.Vedant Kumar2016-11-031-3/+2
| | | | | | | | | | | The assignment to NextIsDereference is either followed by (1) another, unrelated assignment to NextIsDereference or by (2) an early loop exit. Found by clang's static analyzer: http://llvm.org/reports/scan-build (While we're at it fix a typo.) llvm-svn: 285879
* A compound literal within a global lambda or block is still withinJohn McCall2016-10-311-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | the body of a function for the purposes of computing its storage duration and deciding whether its initializer must be constant. There are a number of problems in our current treatment of compound literals. C specifies that a compound literal yields an l-value referring to an object with either static or automatic storage duration, depending on where it was written; in the latter case, the literal object has a lifetime tied to the enclosing scope (much like an ObjC block), not the enclosing full-expression. To get these semantics fully correct in our current design, we would need to collect compound literals on the ExprWithCleanups, just like we do with ObjC blocks; we would probably also want to identify literals like we do with materialized temporaries. But it gets stranger; GCC adds compound literals to C++ as an extension, but makes them r-values, which are generally assumed to have temporary storage duration. Ignoring destructor ordering, the difference only matters if the object's address escapes the full-expression, which for an r-value can only happen with reference binding (which extends temporaries) or array-to-pointer decay (which does not). GCC then attempts to lock down on array-to-pointer decay in ad hoc ways. Arguably a far superior language solution for C++ (and perhaps even array r-values in C, which can occur in other ways) would be to propagate lifetime extension through array-to-pointer decay, so that initializing a pointer object to a decayed r-value array extends the lifetime of the complete object containing the array. But this would be a major change in semantics which arguably ought to be blessed by the committee(s). Anyway, I'm not fixing any of that in this patch; I did try, but it got out of hand. Fixes rdar://28949016. llvm-svn: 285643
* Expand -Wlogical-not-parentheses to also fire on `!x & A`.Nico Weber2016-10-271-11/+20
| | | | | | | | | | | | | This is a misspelling of the intended !(x & A) negated bit test that happens in practice every now and then. I ran this on Chromium and all its dependencies, and it fired 0 times -- no false or true positives, but it would've caught a bug in an in-progress change that had to be caught by a Visual Studio warning instead. https://reviews.llvm.org/D26035 llvm-svn: 285310
* Reapply r284265: "[Sema] Refactor context checking for availability diagnostics"Erik Pilkington2016-10-251-26/+12
| | | | | | | | The problem with the original commit was that some of Apple's headers depended on an incorrect behaviour, this commit adds a temporary workaround until those headers are fixed. llvm-svn: 285098
* [Sema][ObjC] Warn about implicitly autoreleasing out-parameters capturedAkira Hatanaka2016-10-241-0/+17
| | | | | | | | | | | | | | by blocks. Add a new warning "-Wblock-capture-autoreleasing". The warning warns about implicitly autoreleasing out-parameters captured by blocks which can introduce use-after-free bugs that are hard to debug. rdar://problem/15377548 Differential Revision: https://reviews.llvm.org/D25844 llvm-svn: 285031
* DR583, DR1512: Implement a rewrite to C++'s 'composite pointer type' rules.Richard Smith2016-10-211-82/+111
| | | | | | | | | | | | | | | | | | | | | | | | | | 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. This is a re-commit of r284800. llvm-svn: 284890
* Revert "DR583, DR1512: Implement a rewrite to C++'s 'composite pointer type' ↵Renato Golin2016-10-211-111/+82
| | | | | | | | 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-211-82/+111
| | | | | | | | | | | | | | | | | | | | | | | | 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
* [Sema] Gcc compatibility of vector shiftAndrey Bokhanko2016-10-191-0/+10
| | | | | | | | | | | Gcc prints error if elements of left and right parts of a shift have different sizes. This patch is provided the GCC compatibility. Patch by Vladimir Yakovlev. Differential Revision: https://reviews.llvm.org/D24669 llvm-svn: 284579
* DR1330: instantiate exception-specifications when "needed". We previously didRichard Smith2016-10-181-6/+21
| | | | | | | | | | | | | | | | | | | | 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
* Revert r284265 "[Sema] Refactor context checking for availability diagnostics"Erik Pilkington2016-10-181-12/+26
| | | | | | This has a bug in it, pointed out by Bob Wilson! llvm-svn: 284486
* P0012R1: Make exception specifications be part of the type system. ThisRichard Smith2016-10-161-1/+1
| | | | | | | implements the bulk of the change (modifying the type system to include exception specifications), but not all the details just yet. llvm-svn: 284337
* [Sema] Refactor context checking for availability diagnosticsErik Pilkington2016-10-141-26/+12
| | | | | | | | | This commit combines a couple of redundant functions that do availability attribute context checking into a more correct/simpler one. Differential revision: https://reviews.llvm.org/D25283 llvm-svn: 284265
* Use SubstInitializer instead of SubstExpr when instantiating a defaultRichard Smith2016-10-141-1/+2
| | | | | | argument, in order to correctly instantiate the initializer. llvm-svn: 284184
* [CUDA] Do a better job at detecting wrong-side calls.Justin Lebar2016-10-081-71/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Move CheckCUDACall from ActOnCallExpr and BuildDeclRefExpr to DiagnoseUseOfDecl. This lets us catch some edge cases we were missing, specifically around class operators. This necessitates a few other changes: - Avoid emitting duplicate deferred diags in CheckCUDACall. Previously we'd carefully placed our call to CheckCUDACall such that it would only ever run once for a particular callsite. But now this isn't the case. - Emit deferred diagnostics from a template specialization/instantiation's primary template, in addition to from the specialization/instantiation itself. DiagnoseUseOfDecl ends up putting the deferred diagnostics on the template, rather than the specialization, so we need to check both. Reviewers: rsmith Subscribers: cfe-commits, tra Differential Revision: https://reviews.llvm.org/D24573 llvm-svn: 283637
* PR25890: Fix incoherent error handling in PerformImplicitConversion andRichard Smith2016-10-061-7/+9
| | | | | | | | | | | | 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
* [Sema] Replace smart quote with "'" in comment.Justin Lebar2016-10-061-1/+1
| | | | | | | | | | Looks like the smart quote was copy/pasted from the C++ standard. The smart quote was not encoded as valid UTF-8 (?), even though vim was detecting the file as UTF-8. This broke the clang-format Python script, which tried to read the file using the same encoding as vim detected. llvm-svn: 283487
* [MS] Move hex long long sign compat hack to -fms-compatibilityReid Kleckner2016-10-041-1/+1
| | | | | | | | | Treating large 0x*LL literals as signed instead of unsigned is not a conforming language extension, so move it out of -fms-extensions. Came up in PR30605 llvm-svn: 283227
* [Sema] Support lax conversions for compound assignmentsBruno Cardoso Lopes2016-09-301-9/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Support lax convertions on compound assignment expressions like: typedef __attribute__((vector_size(8))) double float64x1_t; typedef __attribute__((vector_size(16))) double float64x2_t; float64x1_t vget_low_f64(float64x2_t __p0); double c = 3.0; float64x2_t v = {0.0, 1.0}; c += vget_low_f64(v); This restores one more valid behavior pre r266366, and is a incremental follow up from work committed in r274646. While here, make the check more strict, add FIXMEs, clean up variable names to match what they can actually be and update testcases to reflect that. We now reject: typedef float float2 __attribute__ ((vector_size (8))); double d; f2 += d; which doesn't fit as a direct bitcast anyway. Differential Revision: https://reviews.llvm.org/D24472 rdar://problem/28033929 llvm-svn: 282968
* Move UTF functions into namespace llvm.Justin Lebar2016-09-301-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This lets people link against LLVM and their own version of the UTF library. I determined this only affects llvm, clang, lld, and lldb by running $ git grep -wl 'UTF[0-9]\+\|\bConvertUTF\bisLegalUTF\|getNumBytesFor' | cut -f 1 -d '/' | sort | uniq clang lld lldb llvm Tested with ninja lldb ninja check-clang check-llvm check-lld (ninja check-lldb doesn't complete for me with or without this patch.) Reviewers: rnk Subscribers: klimek, beanz, mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D24996 llvm-svn: 282822
* [OpenCL] Diagnose assignment to dereference of half type pointerYaxun Liu2016-09-191-0/+10
| | | | | | Differential Revision: https://reviews.llvm.org/D24626 llvm-svn: 281904
* Reverting r281714 due to causing an assert when calling builtins that expect ↵Neil Hickey2016-09-191-19/+3
| | | | | | a double, from CL llvm-svn: 281899
* Improve handling of floating point literals in OpenCL to only use double ↵Neil Hickey2016-09-161-3/+19
| | | | | | | | precision if the target supports fp64 https://reviews.llvm.org/D24235 llvm-svn: 281714
* [Sema] Allow shifting a scalar operand by a vector operand.Akira Hatanaka2016-09-151-5/+20
| | | | | | | | | | | | r278501 inadvertently introduced a bug in which it disallowed shifting scalar operands by vector operands when not compiling for OpenCL. This commit fixes it. Patch by Vladimir Yakovlev. Differential Revision: https://reviews.llvm.org/D24467 llvm-svn: 281669
* ObjectiveC generics: Add ObjCTypeParamType in the type system.Manman Ren2016-09-131-0/+1
| | | | | | | | | | | | | | | | | We also need to add ObjCTypeParamTypeLoc. ObjCTypeParamType supports the representation of "T <protocol>" where T is a type parameter. Before this, we use TypedefType to represent the type parameter for ObjC. ObjCTypeParamType has "ObjCTypeParamDecl *OTPDecl" and it extends from ObjCProtocolQualifiers. It is a non-canonical type and is canonicalized to the underlying type with the protocol qualifiers. rdar://24619481 rdar://25060179 Differential Revision: http://reviews.llvm.org/D23079 llvm-svn: 281355
* PR12298 et al: don't recursively instantiate a template specialization fromRichard Smith2016-08-311-0/+5
| | | | | | | | | | | | | | | within the instantiation of that same specialization. This could previously happen for eagerly-instantiated function templates, variable templates, exception specifications, default arguments, and a handful of other cases. We still have an issue here for default template arguments that recursively make use of themselves and likewise for substitution into the type of a non-type template parameter, but in those cases we're producing a different entity each time, so they should instead be caught by the instantiation depth limit. However, currently we will typically run out of stack before we reach it. :( llvm-svn: 280190
OpenPOWER on IntegriCloud