summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaExpr.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Fix crash with interrupt attribute on ARM.Eli Friedman2017-03-141-1/+1
| | | | | | An indirect call has no associated function declaration. llvm-svn: 297694
* [OpenCL] Fix type compatibility check and generic AS mangling.Anastasia Stulova2017-03-101-63/+84
| | | | | | | | | | | | | | | | | | | | 1. Reimplemented conditional operator so that it checks compatibility of unqualified pointees of the 2nd and the 3rd operands (C99, OpenCL v2.0 6.5.15). Define QualTypes compatibility for OpenCL as following: - corresponding types are compatible (C99 6.7.3) - CVR-qualifiers are equal (C99 6.7.3) - address spaces are equal (implementation defined) 2. Added generic address space to Itanium mangling. Review: D30037 Patch by Dmitry Borisenkov! llvm-svn: 297468
* [Sema] Add variable captured by a block to the enclosing lambda'sAkira Hatanaka2017-03-011-2/+3
| | | | | | | | | | | | | | | potential capture list. Fix Sema::getCurLambda() to return the innermost lambda scope when there is a block enclosed in the lambda. Previously, the method would return a nullptr in such cases, which would prevent a variable captured by the enclosed block to be added to the lambda scope's potential capture list. rdar://problem/28412462 Differential Revision: https://reviews.llvm.org/D25556 llvm-svn: 296584
* Rename ActiveTemplateInstantiation to CodeSynthesisContext in preparation forRichard Smith2017-02-231-4/+5
| | | | | | | using it for other kinds of context (where we currently produce context notes in a highly ad-hoc manner). llvm-svn: 295919
* Factor out function to determine whether we're performing a templateRichard Smith2017-02-211-8/+7
| | | | | | | | | instantiation. In preparation for converting the template stack to a more general context stack (so we can include context notes for other kinds of context). llvm-svn: 295686
* Add an explicit derived class of FunctionDecl to model deduction guides ratherRichard Smith2017-02-171-0/+3
| | | | | | | | than just treating them as FunctionDecls with a funny name. No functionality change intended. llvm-svn: 295491
* Use correct fix-it location for -Wblock-capture-autoreleasingAlex Lorenz2017-02-161-2/+24
| | | | | | | | | The '__autoreleasing' keyword should be inserted after the Objective-C pointer type. rdar://30123548 llvm-svn: 295381
* [OpenCL] Disallow blocks capture other blocks (v2.0, s6.12.5)Anastasia Stulova2017-02-161-0/+7
| | | | llvm-svn: 295307
* [c++1z] Diagnose attempts to use variables with deduced class templateRichard Smith2017-02-101-3/+1
| | | | | | specialization types from within their own initializers. llvm-svn: 294796
* [OpenCL] Accept logical NOT for pointer types in CL1.1Anastasia Stulova2017-02-071-1/+1
| | | | | | | | | Fix for bug 30217 - incorrect error given for logical NOT operation with a pointer type: corrected sema check and improved related tests. Review: D29038 llvm-svn: 294313
* Change how we handle diagnose_if attributes.George Burgess IV2017-01-281-18/+1
| | | | | | | | | | | | | This patch changes how we handle argument-dependent `diagnose_if` attributes. In particular, we now check them in the same place that we check for things like passing NULL to Nonnull args, etc. This is basically better in every way than how we were handling them before. :) This fixes PR31638, PR31639, and PR31640. Differential Revision: https://reviews.llvm.org/D28889 llvm-svn: 293360
* [OpenCL] Add missing address spaces in IR generation of blocksAnastasia Stulova2017-01-271-3/+20
| | | | | | | | | | | | | | | | | | | | | | | | Modify ObjC blocks impl wrt address spaces as follows: - keep default private address space for blocks generated as local variables (with captures); - add global address space for global block literals (no captures); - make the block invoke function and enqueue_kernel prototype with the generic AS block pointer parameter to accommodate both private and global AS cases from above; - add block handling into default AS because it's implemented as a special pointer type (BlockPointer) in the frontend and therefore it is used as a pointer everywhere. This is also needed to accommodate both private and global AS blocks for the two cases above. - removes ObjC RT specific symbols (NSConcreteStackBlock and NSConcreteGlobalBlock) in the OpenCL mode. Review: https://reviews.llvm.org/D28814 llvm-svn: 293286
* PR0091R3: Implement parsing support for using templates as types.Richard Smith2017-01-261-1/+2
| | | | | | | | | | | | | | | This change adds a new type node, DeducedTemplateSpecializationType, to represent a type template name that has been used as a type. This is modeled around AutoType, and shares a common base class for representing a deduced placeholder type. We allow deduced class template types in a few more places than the standard does: in conditions and for-range-declarators, and in new-type-ids. This is consistent with GCC and with discussion on the core reflector. This patch does not yet support deduced class template types being named in typename specifiers. llvm-svn: 293207
* [Sema][ObjC] Make sure -Wblock-capture-autoreleasing issues a warningAkira Hatanaka2017-01-261-3/+20
| | | | | | | | | | | | | | | even in the presence of nullability qualifiers. This commit fixes bugs in r285031 where -Wblock-capture-autoreleasing wouldn't issue warnings when the function parameters were annotated with nullability qualifiers. Specifically, look through the sugar and see if there is an AttributedType of kind attr_objc_ownership to determine whether __autoreleasing was explicitly specified or implicitly added by the compiler. rdar://problem/30193488 llvm-svn: 293194
* [Sema] Fix PR28181 by avoiding calling BuildOverloadedBinOp in C modeAlex Lorenz2017-01-191-6/+5
| | | | | | | | rdar://28532840 Differential Revision: https://reviews.llvm.org/D25213 llvm-svn: 292497
* Warn when calling a non interrupt function from an interrupt on ARMJonathan Roelofs2017-01-181-0/+9
| | | | | | | | | | The idea for this originated from a really tricky bug: ISRs on ARM don't automatically save off the VFP regs, so if say, memcpy gets interrupted and the ISR itself calls memcpy, the regs are left clobbered when the ISR is done. https://reviews.llvm.org/D28820 llvm-svn: 292375
* [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
OpenPOWER on IntegriCloud