summaryrefslogtreecommitdiff
path: root/lib/Sema/SemaExpr.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [OPENMP5.0]Introduce attribute for declare variant directive.Alexey Bataev2019-09-171-0/+1
| | | | | | | | Added attribute for declare variant directive. It will allow to handle declare variant directive at the codegen and will allow to add extra checks. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@372147 91177308-0d34-0410-b5e6-96231b3b80d8
* [Diagnostics] Added silence note for -Wsizeof-array-div; suggest extra parensDavid Bolvansky2019-09-141-0/+2
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@371924 91177308-0d34-0410-b5e6-96231b3b80d8
* For PR17164: split -fno-lax-vector-conversion into three differentRichard Smith2019-09-131-1/+21
| | | | | | | | | | | | | | | | | | | | | levels: -- none: no lax vector conversions [new GCC default] -- integer: only conversions between integer vectors [old GCC default] -- all: all conversions between same-size vectors [Clang default] For now, Clang still defaults to "all" mode, but per my proposal on cfe-dev (2019-04-10) the default will be changed to "integer" as soon as that doesn't break lots of testcases. (Eventually I'd like to change the default to "none" to match GCC and general sanity.) Following GCC's behavior, the driver flag -flax-vector-conversions is translated to -flax-vector-conversions=integer. This reinstates r371805, reverted in r371813, with an additional fix for lldb. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@371817 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "For PR17164: split -fno-lax-vector-conversion into three different"Jonas Devlieghere2019-09-131-21/+1
| | | | | | | This breaks the LLDB build. I tried reaching out to Richard, but haven't gotten a reply yet. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@371813 91177308-0d34-0410-b5e6-96231b3b80d8
* For PR17164: split -fno-lax-vector-conversion into three differentRichard Smith2019-09-131-1/+21
| | | | | | | | | | | | | | | | | | levels: -- none: no lax vector conversions [new GCC default] -- integer: only conversions between integer vectors [old GCC default] -- all: all conversions between same-size vectors [Clang default] For now, Clang still defaults to "all" mode, but per my proposal on cfe-dev (2019-04-10) the default will be changed to "integer" as soon as that doesn't break lots of testcases. (Eventually I'd like to change the default to "none" to match GCC and general sanity.) Following GCC's behavior, the driver flag -flax-vector-conversions is translated to -flax-vector-conversions=integer. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@371805 91177308-0d34-0410-b5e6-96231b3b80d8
* [Diagnostics] Add -Wsizeof-array-divDavid Bolvansky2019-09-111-10/+21
| | | | | | | | | | Summary: Clang version of https://www.viva64.com/en/examples/v706/ Reviewers: rsmith Differential Revision: https://reviews.llvm.org/D67287 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@371605 91177308-0d34-0410-b5e6-96231b3b80d8
* PR43242: Fix crash when typo-correcting to an operator() that should notRichard Smith2019-09-091-10/+1
| | | | | | have been visible. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@371468 91177308-0d34-0410-b5e6-96231b3b80d8
* [Sema][ObjC] Mark C union fields that have non-trivial ObjC ownershipAkira Hatanaka2019-09-071-17/+1
| | | | | | | | | | | | | | | | | qualifications as unavailable if the union is declared in a system header r365985 stopped marking those fields as unavailable, which caused the union's NonTrivialToPrimitive* bits to be set to true. This patch restores the behavior prior to r365985, except that users can explicitly specify the ownership qualification of the field to instruct the compiler not to mark it as unavailable. rdar://problem/53420753 Differential Revision: https://reviews.llvm.org/D65256 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@371276 91177308-0d34-0410-b5e6-96231b3b80d8
* [Sema] Diagnose default-initialization, destruction, and copying ofAkira Hatanaka2019-09-071-1/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | non-trivial C union types This recommits r365985, which was reverted because it broke a few projects using unions containing non-trivial ObjC pointer fields in system headers. We now have a patch to fix the problem (see https://reviews.llvm.org/D65256). Original commit message: This patch diagnoses uses of non-trivial C unions and structs/unions containing non-trivial C unions in the following contexts, which require default-initialization, destruction, or copying of the union objects, instead of disallowing fields of non-trivial types in C unions, which is what we currently do: - function parameters. - function returns. - assignments. - compound literals. - block captures except capturing of `__block` variables by non-escaping blocks. - local and global variable definitions. - lvalue-to-rvalue conversions of volatile types. See the discussion in https://reviews.llvm.org/D62988 for more background. rdar://problem/50679094 Differential Revision: https://reviews.llvm.org/D63753 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@371275 91177308-0d34-0410-b5e6-96231b3b80d8
* [NFCI] Unbreak buildbotsDavid Bolvansky2019-09-061-22/+10
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@371226 91177308-0d34-0410-b5e6-96231b3b80d8
* [Diagnostics] Refactor code for -Wsizeof-pointer-div, catch more cases; also ↵David Bolvansky2019-09-061-11/+24
| | | | | | | | | | | | | | | | | | add -Wsizeof-array-div Previously, -Wsizeof-pointer-div failed to catch: const int *r; sizeof(r) / sizeof(int); Now fixed. Also introduced -Wsizeof-array-div which catches bugs like: sizeof(r) / sizeof(short); (Array element type does not match type of sizeof operand). git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@371222 91177308-0d34-0410-b5e6-96231b3b80d8
* [Diagnostics] Minor improvements for -Wxor-used-as-powDavid Bolvansky2019-09-051-22/+35
| | | | | | | | Extracted from D66397; implemented suggestion for 2^64; tests revisited. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@371122 91177308-0d34-0410-b5e6-96231b3b80d8
* [c++20] Implement semantic restrictions for C++20 designatedRichard Smith2019-08-301-3/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | initializers. This has some interesting interactions with our existing extensions to support C99 designated initializers as an extension in C++. Those are resolved as follows: * We continue to permit the full breadth of C99 designated initializers in C++, with the exception that we disallow a partial overwrite of an initializer with a non-trivially-destructible type. (Full overwrite is OK, because we won't run the first initializer at all.) * The C99 extensions are disallowed in SFINAE contexts and during overload resolution, where they could change the meaning of valid programs. * C++20 disallows reordering of initializers. We only check for that for the simple cases that the C++20 rules permit (designators of the form '.field_name =' and continue to allow reordering in other cases). It would be nice to improve this behavior in future. * All C99 designated initializer extensions produce a warning by default in C++20 mode. People are going to learn the C++ rules based on what Clang diagnoses, so it's important we diagnose these properly by default. * In C++ <= 17, we apply the C++20 rules rather than the C99 rules, and so still diagnose C99 extensions as described above. We continue to accept designated C++20-compatible initializers in C++ <= 17 silently by default (but naturally still reject under -pedantic-errors). This is not a complete implementation of P0329R4. In particular, that paper introduces new non-C99-compatible syntax { .field { init } }, and we do not support that yet. This is based on a previous patch by Don Hinton, though I've made substantial changes when addressing the above interactions. Differential Revision: https://reviews.llvm.org/D59754 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@370544 91177308-0d34-0410-b5e6-96231b3b80d8
* Improve behavior in the case of stack exhaustion.Richard Smith2019-08-261-88/+106
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Clang performs various recursive operations (such as template instantiation), and may use non-trivial amounts of stack space in each recursive step (for instance, due to recursive AST walks). While we try to keep the stack space used by such steps to a minimum and we have explicit limits on the number of such steps we perform, it's impractical to guarantee that we won't blow out the stack on deeply recursive template instantiations on complex ASTs, even with only a moderately high instantiation depth limit. The user experience in these cases is generally terrible: we crash with no hint of what went wrong. Under this patch, we attempt to do better: * Detect when the stack is nearly exhausted, and produce a warning with a nice template instantiation backtrace, telling the user that we might run slowly or crash. * For cases where we're forced to trigger recursive template instantiation in arbitrarily-deeply-nested contexts, check whether we're nearly out of stack space and allocate a new stack (by spawning a new thread) after producing the warning. Reviewers: rnk, aaron.ballman Subscribers: mgorny, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66361 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@369940 91177308-0d34-0410-b5e6-96231b3b80d8
* [OPENMP5.0]Add support for device_type clause in declare targetAlexey Bataev2019-08-231-2/+6
| | | | | | | | | | construct. OpenMP 5.0 introduced new clause for declare target directive, device_type clause, which may accept values host, nohost, and any. Host means that the function must be emitted only for the host, nohost - only for the device, and any - for both, device and the host. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@369775 91177308-0d34-0410-b5e6-96231b3b80d8
* [OpenMP] Permit map with DSA on combined directiveJoel E. Denny2019-08-221-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | For `map`, the following restriction changed in OpenMP 5.0: * OpenMP 4.5 [2.15.5.1, Restrictions]: "A list item cannot appear in both a map clause and a data-sharing attribute clause on the same construct. * OpenMP 5.0 [2.19.7.1, Restrictions]: "A list item cannot appear in both a map clause and a data-sharing attribute clause on the same construct unless the construct is a combined construct." This patch removes this restriction in the case of combined constructs and OpenMP 5.0, and it updates Sema not to capture a scalar by copy in the target region when `firstprivate` and `map` appear for that scalar on a combined target construct. This patch also adds a fixme to a test that now reveals that a diagnostic about loop iteration variables is dropped in the case of OpenMP 5.0. That bug exists regardless of this patch's changes. Reviewed By: ABataev, jdoerfert, hfinkel, kkwli0 Differential Revision: https://reviews.llvm.org/D65835 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@369619 91177308-0d34-0410-b5e6-96231b3b80d8
* [Diagnostics] Diagnose misused xor as powDavid Bolvansky2019-08-181-1/+105
| | | | | | | | | | | | | | | | | | | | Summary: Motivation: https://twitter.com/jfbastien/status/1139298419988549632 https://twitter.com/mikemx7f/status/1139335901790625793 https://codesearch.isocpp.org/cgi-bin/cgi_ppsearch?q=10+%5E&search=Search Reviewers: jfb, rsmith, regehr, aaron.ballman Reviewed By: aaron.ballman Subscribers: lebedev.ri, Quuxplusone, erik.pilkington, riccibruno, dexonsmith, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D63423 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@369217 91177308-0d34-0410-b5e6-96231b3b80d8
* [Diagnostics] Improve -Wsizeof-pointer-divDavid Bolvansky2019-08-181-2/+8
| | | | | | | | | Emit diag note with a location of pointer declaration. Revisited/added tests. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@369206 91177308-0d34-0410-b5e6-96231b3b80d8
* [Clang] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-141-1/+1
| | | | | | | | | | Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. Differential revision: https://reviews.llvm.org/D66259 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@368942 91177308-0d34-0410-b5e6-96231b3b80d8
* Add SVE opaque built-in typesRichard Sandiford2019-08-091-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds the SVE built-in types defined by the Procedure Call Standard for the Arm Architecture: https://developer.arm.com/docs/100986/0000 It handles the types in all relevant places that deal with built-in types. At the moment, some of these places bail out with an error, including: (1) trying to generate LLVM IR for the types (2) trying to generate debug info for the types (3) trying to mangle the types using the Microsoft C++ ABI (4) trying to @encode the types in Objective C (1) and (2) are fixed by follow-on patches but (unlike this patch) they deal mostly with target-specific LLVM details, so seemed like a logically separate change. There is currently no spec for (3) and (4), so reporting an error seems like the correct behaviour for now. The intention is that the types will become sizeless types: http://lists.llvm.org/pipermail/cfe-dev/2019-June/062523.html The main purpose of the sizeless type extension is to diagnose impossible or dangerous uses of the types, such as any that would require sizeof to have a meaningful defined value. Until then, the patch sets the alignments of the types to the values specified in the link above. It also sets the sizes of the types to zero, which is chosen to be consistently wrong and shouldn't affect correctly-written code (i.e. code that would compile even with the sizeless type extension). The patch adds the common subset of functionality needed to test the sizeless type extension on the one hand and to provide SVE intrinsic functions on the other. After this patch, the two pieces of work are essentially independent. The patch is based on one by Graham Hunter: https://reviews.llvm.org/D59245 Differential Revision: https://reviews.llvm.org/D62960 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@368413 91177308-0d34-0410-b5e6-96231b3b80d8
* Inline diagnostic text into .td file. NFC.Richard Trieu2019-08-081-9/+19
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@368244 91177308-0d34-0410-b5e6-96231b3b80d8
* [Sema] Add -Wpointer-compareGeorge Burgess IV2019-08-051-0/+30
| | | | | | | | | | | | This patch adds a warning that diagnoses comparisons of pointers to '\0'. This is often indicative of a bug (e.g. the user might've forgotten to dereference the pointer). Patch by Elaina Guan! Differential Revision: https://reviews.llvm.org/D65595 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@367940 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "[Sema] Diagnose default-initialization, destruction, and copying of"Akira Hatanaka2019-07-261-32/+1
| | | | | | | | | | | | | | | This reverts commit r365985. Prior to r365985, clang used to mark C union fields that have non-trivial ObjC ownership qualifiers as unavailable if the union was declared in a system header. r365985 stopped doing so, which caused the swift compiler to crash when it tried to import a non-trivial union. I have a patch that fixes the crash (https://reviews.llvm.org/D65256), but I'm temporarily reverting the original patch until we can decide on whether it's taking the right approach. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@367076 91177308-0d34-0410-b5e6-96231b3b80d8
* Allow prefetching from non-zero address spacesJF Bastien2019-07-251-2/+3
| | | | | | | | | | | | | | | Summary: This is useful for targets which have prefetch instructions for non-default address spaces. <rdar://problem/42662136> Subscribers: nemanjai, javed.absar, hiraditya, kbarton, jkorous, dexonsmith, cfe-commits, llvm-commits, RKSimon, hfinkel, t.p.northover, craig.topper, anemet Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D65254 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@367032 91177308-0d34-0410-b5e6-96231b3b80d8
* [c++20] P1161R3: a[b,c] is deprecated.Richard Smith2019-07-201-0/+9
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@366630 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix parameter name comments using clang-tidy. NFC.Rui Ueyama2019-07-161-15/+15
| | | | | | | | | | | | | | | | | | | | | 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} git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@366177 91177308-0d34-0410-b5e6-96231b3b80d8
* [Sema] Diagnose default-initialization, destruction, and copying ofAkira Hatanaka2019-07-131-1/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | non-trivial C union types This patch diagnoses uses of non-trivial C unions and structs/unions containing non-trivial C unions in the following contexts, which require default-initialization, destruction, or copying of the union objects, instead of disallowing fields of non-trivial types in C unions, which is what we currently do: - function parameters. - function returns. - assignments. - compound literals. - block captures except capturing of `__block` variables by non-escaping blocks. - local and global variable definitions. - lvalue-to-rvalue conversions of volatile types. See the discussion in https://reviews.llvm.org/D62988 for more background. rdar://problem/50679094 Differential Revision: https://reviews.llvm.org/D63753 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@365985 91177308-0d34-0410-b5e6-96231b3b80d8
* [OpenCL][Sema] Fix builtin rewritingMarco Antognini2019-07-091-2/+2
| | | | | | | | | | | This patch ensures built-in functions are rewritten using the proper parent declaration. Existing tests are modified to run in C++ mode to ensure the functionality works also with C++ for OpenCL while not increasing the testing runtime. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@365499 91177308-0d34-0410-b5e6-96231b3b80d8
* Ignore trailing NullStmts in StmtExprs for GCC compatibility.Aaron Ballman2019-07-091-1/+3
| | | | | | | | Ignore trailing NullStmts in compound expressions when determining the result type and value. This is to match the GCC behavior which ignores semicolons at the end of compound expressions. Patch by Dominic Ferreira. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@365498 91177308-0d34-0410-b5e6-96231b3b80d8
* 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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@365393 91177308-0d34-0410-b5e6-96231b3b80d8
* [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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@365382 91177308-0d34-0410-b5e6-96231b3b80d8
* [OPENMP]Fix handling of lambda captures in target regions.Alexey Bataev2019-07-011-0/+2
| | | | | | | | Previously, lambda captures were processed in the function called during capturing the variables. It leads to the recursive functions calls and may result in the compiler crash. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@364820 91177308-0d34-0410-b5e6-96231b3b80d8
* [cxx2a] P1236R1: the validity of a left shift does not depend on theRichard Smith2019-06-251-5/+8
| | | | | | value of the LHS operand. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@364265 91177308-0d34-0410-b5e6-96231b3b80d8
* clang-format a block; NFCGeorge Burgess IV2019-06-211-6/+7
| | | | | | | The indentation of the return here was off, and confusing as a result. Cleaned up a bit extra while I was in the area. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@364104 91177308-0d34-0410-b5e6-96231b3b80d8
* [OPENMP]Fix PR42068: Vla type is not captured.Alexey Bataev2019-06-211-0/+27
| | | | | | | | If the variably modified type is declared outside of the captured region and then used in the cast expression along with array subscript expression, the type is not captured and it leads to the compiler crash. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@364080 91177308-0d34-0410-b5e6-96231b3b80d8
* [clang] Small improvments after Adding APValue to ConstantExprGauthier Harnisch2019-06-211-5/+8
| | | | | | | | | | | | | | | | | | | | | | | Summary: this patch has multiple small improvements related to the APValue in ConstantExpr. changes: - APValue in ConstantExpr are now cleaned up using ASTContext::addDestruction instead of there own system. - ConstantExprBits Stores the ValueKind of the result beaing stored. - VerifyIntegerConstantExpression now stores the evaluated value in ConstantExpr. - the Constant Evaluator uses the stored value of ConstantExpr when available. Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D63376 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@364011 91177308-0d34-0410-b5e6-96231b3b80d8
* PR23833, DR2140: an lvalue-to-rvalue conversion on a glvalue of typeRichard Smith2019-06-141-2/+4
| | | | | | | | | | | nullptr_t does not access memory. We now reuse CK_NullToPointer to represent a conversion from a glvalue of type nullptr_t to a prvalue of nullptr_t where necessary. This reinstates r363337, reverted in r363352. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@363429 91177308-0d34-0410-b5e6-96231b3b80d8
* C++ DR712 and others: handle non-odr-use resulting from an lvalue-to-rvalue ↵Richard Smith2019-06-141-26/+127
| | | | | | | | | | | | | | | | | | | | | | | | | | | conversion applied to a member access or similar not-quite-trivial lvalue expression. Summary: When a variable is named in a context where we can't directly emit a reference to it (because we don't know for sure that it's going to be defined, or it's from an enclosing function and not captured, or the reference might not "work" for some reason), we emit a copy of the variable as a global and use that for the known-to-be-read-only access. This reinstates r363295, reverted in r363352, with a fix for PR42276: we now produce a proper name for a non-odr-use reference to a static constexpr data member. The name <mangled-name>.const is used in that case; such names are reserved to the implementation for cases such as this and should demangle nicely. Reviewers: rjmccall Subscribers: jdoerfert, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D63157 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@363428 91177308-0d34-0410-b5e6-96231b3b80d8
* [C++20] add Basic consteval specifierGauthier Harnisch2019-06-141-7/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: this revision adds Lexing, Parsing and Basic Semantic for the consteval specifier as specified by http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1073r3.html with this patch, the consteval specifier is treated as constexpr but can only be applied to function declaration. Changes: - add the consteval keyword. - add parsing of consteval specifier for normal declarations and lambdas expressions. - add the whether a declaration is constexpr is now represented by and enum everywhere except for variable because they can't be consteval. - adapt diagnostic about constexpr to print constexpr or consteval depending on the case. - add tests for basic semantic. Reviewers: rsmith, martong, shafik Reviewed By: rsmith Subscribers: eraman, efriedma, rnkovacs, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D61790 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@363362 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert 363295, it caused PR42276. Also revert follow-ups 363337, 363340.Nico Weber2019-06-141-131/+28
| | | | | | | | Revert 363340 "Remove unused SK_LValueToRValue initialization step." Revert 363337 "PR23833, DR2140: an lvalue-to-rvalue conversion on a glvalue of type" Revert 363295 "C++ DR712 and others: handle non-odr-use resulting from an lvalue-to-rvalue conversion applied to a member access or similar not-quite-trivial lvalue expression." git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@363352 91177308-0d34-0410-b5e6-96231b3b80d8
* PR23833, DR2140: an lvalue-to-rvalue conversion on a glvalue of typeRichard Smith2019-06-131-2/+4
| | | | | | | | | | | | nullptr_t does not access memory. We now reuse CK_NullToPointer to represent a conversion from a glvalue of type nullptr_t to a prvalue of nullptr_t where necessary. This reinstates r345562, reverted in r346065, now that CodeGen's handling of non-odr-used variables has been fixed. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@363337 91177308-0d34-0410-b5e6-96231b3b80d8
* C++ DR712 and others: handle non-odr-use resulting from an lvalue-to-rvalue ↵Richard Smith2019-06-131-26/+127
| | | | | | | | | | | | | | | | | | | | | conversion applied to a member access or similar not-quite-trivial lvalue expression. Summary: When a variable is named in a context where we can't directly emit a reference to it (because we don't know for sure that it's going to be defined, or it's from an enclosing function and not captured, or the reference might not "work" for some reason), we emit a copy of the variable as a global and use that for the known-to-be-read-only access. Reviewers: rjmccall Subscribers: jdoerfert, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D63157 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@363295 91177308-0d34-0410-b5e6-96231b3b80d8
* Mark declarations as referenced by a default argument in aRichard Smith2019-06-111-0/+2
| | | | | | | | | potentially-evaluated context. This applies even if the use of the default argument is within an unevaluated context. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@363113 91177308-0d34-0410-b5e6-96231b3b80d8
* For DR712: store on a MemberExpr whether it constitutes an odr-use.Richard Smith2019-06-111-26/+47
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@363087 91177308-0d34-0410-b5e6-96231b3b80d8
* For DR712: store on a DeclRefExpr whether it constitutes an odr-use.Richard Smith2019-06-111-71/+281
| | | | | | | Begin restructuring to support the forms of non-odr-use reference permitted by DR712. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@363086 91177308-0d34-0410-b5e6-96231b3b80d8
* Require stdcall etc parameters to be complete on ODR useReid Kleckner2019-06-101-0/+81
| | | | | | | | | | | | | | | | | | | Functions using stdcall, fastcall, or vectorcall with C linkage mangle in the size of the parameter pack. Calculating the size of the pack requires the parameter types to complete, which may require template instantiation. Previously, we would crash during IRgen when requesting the size of incomplete or uninstantiated types, as in this reduced example: struct Foo; void __fastcall bar(struct Foo o); void (__fastcall *fp)(struct Foo) = &bar; Reported in Chromium here: https://crbug.com/971245 Differential Revision: https://reviews.llvm.org/D62975 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@363000 91177308-0d34-0410-b5e6-96231b3b80d8
* Factor out repeated code to build a DeclRefExpr and mark it referenced.Richard Smith2019-06-041-24/+22
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@362537 91177308-0d34-0410-b5e6-96231b3b80d8
* PR42104: Support instantiations of lambdas that implicitly captureRichard Smith2019-06-041-17/+31
| | | | | | | | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@362531 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert rL362358 : PR42104: Support instantiations of lambdas that implicitly ↵Simon Pilgrim2019-06-031-31/+19
| | | | | | | | | | | | | | | | 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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@362375 91177308-0d34-0410-b5e6-96231b3b80d8
* PR42104: Support instantiations of lambdas that implicitly captureRichard Smith2019-06-031-19/+31
| | | | | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@362358 91177308-0d34-0410-b5e6-96231b3b80d8
View Lorry Controller Status