summaryrefslogtreecommitdiffstats
path: root/clang/test
Commit message (Collapse)AuthorAgeFilesLines
* [MS] Emit vftable thunks for functions with incomplete prototypesReid Kleckner2018-04-022-0/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The following class hierarchy requires that we be able to emit a this-adjusting thunk for B::foo in C's vftable: struct Incomplete; struct A { virtual A* foo(Incomplete p) = 0; }; struct B : virtual A { void foo(Incomplete p) override; }; struct C : B { int c; }; This TU is valid, but lacks a definition of 'Incomplete', which makes it hard to build a thunk for the final overrider, B::foo. Before this change, Clang gives up attempting to emit the thunk, because it assumes that if the parameter types are incomplete, it must be emitting the thunk for optimization purposes. This is untrue for the MS ABI, where the implementation of B::foo has no idea what thunks C's vftable may require. Clang needs to emit the thunk without necessarily having access to the complete prototype of foo. This change makes Clang emit a musttail variadic call when it needs such a thunk. I call these "unprototyped" thunks, because they only prototype the "this" parameter, which must always come first in the MS C++ ABI. These thunks work, but they create ugly LLVM IR. If the call to the thunk is devirtualized, it will be a call to a bitcast of a function pointer. Today, LLVM cannot inline through such a call, but I want to address that soon, because we also use this pattern for virtual member pointer thunks. This change also implements an old FIXME in the code about reusing the thunk's computed CGFunctionInfo as much as possible. Now we don't end up computing the thunk's mangled name and arranging it's prototype up to around three times. Fixes PR25641 Reviewers: rjmccall, rsmith, hans Subscribers: Prazek, cfe-commits Differential Revision: https://reviews.llvm.org/D45112 llvm-svn: 329009
* Temporarily revert r328404:Eric Christopher2018-04-021-122/+0
| | | | | | | | | | | | | | commit 519b97132a4c960e8dedbfe4290d86970d92e995 Author: Richard Trieu <rtrieu@google.com> Date: Sat Mar 24 00:52:44 2018 +0000 [ODRHash] Support pointer and reference types. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@328404 91177308-0d34-0410-b5e6-96231b3b80d8 As it's breaking some tests. I've communicated with Richard offline about testcases. llvm-svn: 329001
* [CUDA] Let device-side shared variables be initialized with undefYaxun Liu2018-04-022-36/+93
| | | | | | | | | | | CUDA shared variable should be initialized with undef. Patch by Greg Rodgers. Revised and lit test added by Yaxun Liu. Differential Revision: https://reviews.llvm.org/D44985 llvm-svn: 328994
* [coroutines] Add __builtin_coro_noop => llvm.coro.noopGor Nishanov2018-04-021-0/+3
| | | | | | | | | | | | | A recent addition to Coroutines TS (https://wg21.link/p0913) adds a pre-defined coroutine noop_coroutine that does nothing. To implement this feature, we implemented an llvm.coro.noop intrinsic that returns a coroutine handle to a coroutine that does nothing when resumed or destroyed. This patch adds a builtin __builtin_coro_noop() that maps to llvm.coro.noop intrinsic. Related llvm change: https://reviews.llvm.org/D45114 llvm-svn: 328993
* [Coroutines] Find custom allocators in class scopeBrian Gesiak2018-04-012-56/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: https://reviews.llvm.org/rL325291 implemented Coroutines TS N4723 section [dcl.fct.def.coroutine]/7, but it performed lookup of allocator functions within both the global and class scope, whereas the specified behavior is to perform lookup for custom allocators within just the class scope. To fix, add parameters to the `Sema::FindAllocationFunctions` function such that it can be used to lookup allocators in global scope, class scope, or both (instead of just being able to look up in just global scope or in both global and class scope). Then, use those parameters from within the coroutine Sema. This incorrect behavior had the unfortunate side-effect of causing the bug https://bugs.llvm.org/show_bug.cgi?id=36578 (or at least the reports of that bug in C++ programs). That bug would occur for any C++ user with a coroutine frame that took a single pointer argument, since it would then find the global placement form `operator new`, described in the C++ standard 18.6.1.3.1. This patch prevents Clang from generating code that triggers the LLVM assert described in that bug report. Test Plan: `check-clang` Reviewers: GorNishanov, eric_niebler, lewissbaker Reviewed By: GorNishanov Subscribers: EricWF, cfe-commits Differential Revision: https://reviews.llvm.org/D44552 llvm-svn: 328949
* Fix a major swiftcall ABI bug with trivial C++ class types.John McCall2018-04-011-0/+10
| | | | | | | | | | | | | | | | | | | | | | The problem with the previous logic was that there might not be any explicit copy/move constructor declarations, e.g. if the type is trivial and we've never type-checked a copy of it. Relying on Sema's computation seems much more reliable. Also, I believe Richard's recommendation is exactly the rule we use now on the Itanium ABI, modulo the trivial_abi attribute (which this change of course fixes our handling of in Swift). This does mean that we have a less portable rule for deciding indirectness for swiftcall. I would prefer it if we just applied the Itanium rule universally under swiftcall, but in the meantime, I need to fix this bug. This only arises when defining functions with class-type arguments in C++, as we do in the Swift runtime. It doesn't affect normal Swift operation because we don't import code as C++. llvm-svn: 328942
* [analyzer] Unroll the loop when it has a unsigned counter.Henry Wong2018-03-311-0/+23
| | | | | | | | | | | | | | | | | Summary: The original implementation in the `LoopUnrolling.cpp` didn't consider the case where the counter is unsigned. This case is only handled in `simpleCondition()`, but this is not enough, we also need to deal with the unsinged counter with the counter initialization. Since `IntegerLiteral` is `signed`, there is a `ImplicitCastExpr<IntegralCast>` in `unsigned counter = IntergerLiteral`. This patch add the `ignoringParenImpCasts()` in the `IntegerLiteral` matcher. Reviewers: szepet, a.sidorin, NoQ, george.karpenkov Reviewed By: szepet, george.karpenkov Subscribers: xazax.hun, rnkovacs, cfe-commits, MTC Differential Revision: https://reviews.llvm.org/D45086 llvm-svn: 328919
* [analyzer] Hopefully fix the ARM buildbot.George Karpenkov2018-03-312-10/+9
| | | | llvm-svn: 328913
* [analyzer] Fix assertion crash in CStringCheckerGeorge Karpenkov2018-03-311-0/+11
| | | | | | | | | | An offset might be unknown. rdar://39054939 Differential Revision: https://reviews.llvm.org/D45115 llvm-svn: 328912
* [analyzer] Fix liveness calculation for C++17 structured bindingsGeorge Karpenkov2018-03-311-0/+124
| | | | | | | | | | | | | C++ structured bindings for non-tuple-types are defined in a peculiar way, where the resulting declaration is not a VarDecl, but a BindingDecl. That means a lot of existing machinery stops working. rdar://36912381 Differential Revision: https://reviews.llvm.org/D44956 llvm-svn: 328910
* [analyzer] Fix test triple in missing-bind-temporary.cpp.Artem Dergachev2018-03-301-2/+2
| | | | | | | | | Otherwise the default triple for x86-windows-msvc2015 auto-inserts __attribute__((thiscall)) to some calls. Fixes the respective buildbot. llvm-svn: 328903
* [analyzer] Track null or undef values through pointer arithmetic.Artem Dergachev2018-03-302-3/+45
| | | | | | | | | | | | | | | | | | Pointer arithmetic on null or undefined pointers results in null or undefined pointers. This is obvious for undefined pointers; for null pointers it follows from our incorrect-but-somehow-working approach that declares that 0 (Loc) doesn't necessarily represent a pointer of numeric address value 0, but instead it represents any pointer that will cause a valid "null pointer dereference" issue when dereferenced. For now we've been seeing through pointer arithmetic at the original dereference expression, i.e. in bugreporter::getDerefExpr(), but not during further investigation of the value's origins in bugreporter::trackNullOrUndefValue(). The patch fixes it. Differential Revision: https://reviews.llvm.org/D45071 llvm-svn: 328896
* [CFG] [analyzer] Work around a disappearing CXXBindTemporaryExpr.Artem Dergachev2018-03-301-0/+130
| | | | | | | | | | | | | Sometimes template instantiation causes CXXBindTemporaryExpr to be missing in its usual spot. In CFG, temporary destructors work by relying on CXXBindTemporaryExprs, so they won't work in this case. Avoid the crash and notify the clients that we've encountered an unsupported AST by failing to provide the ill-formed construction context for the temporary. Differential Revision: https://reviews.llvm.org/D44955 llvm-svn: 328895
* [CFG] [analyzer] Avoid modeling C++17 constructors that aren't fully supported.Artem Dergachev2018-03-303-2/+66
| | | | | | | | | | | | | | Not enough work has been done so far to ensure correctness of construction contexts in the CFG when C++17 copy elision is in effect, so for now we should drop construction contexts in the CFG and in the analyzer when they seem different from what we support anyway. This includes initializations with conditional operators and return values across multiple stack frames. Differential Revision: https://reviews.llvm.org/D44854 llvm-svn: 328893
* Remove unused CHECK lines leftover from r306928.Eli Friedman2018-03-301-4/+0
| | | | | | | The RUN lines were removed, but the corresponding CHECK lines never went away. llvm-svn: 328891
* [OPENMP] Added emission of offloading data sections for declare targetAlexey Bataev2018-03-3033-375/+386
| | | | | | | | | | variables. Added emission of the offloading data sections for the variables within declare target regions + fixes emission of the declare target variables marked as declare target not within the declare target region. llvm-svn: 328888
* [Modules] Improve fixit for framework private module mapsBruno Cardoso Lopes2018-03-301-1/+1
| | | | | | | | | The wrong source range was being provided in some case, fix that to get a better fixit. rdar://problem/38520199 llvm-svn: 328857
* Adding UNSUPPORTED: system-windows at George's request until the problem can ↵Douglas Yung2018-03-301-0/+1
| | | | | | be debugged. llvm-svn: 328853
* [analyzer] Fix target triple for autorelease-write-checker testGeorge Karpenkov2018-03-291-1/+2
| | | | llvm-svn: 328837
* Set dso_local on cfi_slowpath.Rafael Espindola2018-03-291-0/+5
| | | | llvm-svn: 328836
* [AArch64]: Add support for parsing rN registers.Manoj Gupta2018-03-291-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Allow rN registers to be simply parsed as correspoing xN registers. The "register ... asm("rN")" is an command to the compiler's register allocator, not an operand to any individual assembly instruction. GCC documents this syntax as "...the name of the register that should be used." This is needed to support the changes in Linux kernel (see https://lkml.org/lkml/2018/3/1/268 ) Note: This will add support only for the limited use case of register ... asm("rN"). Any other uses that make rN leak into assembly are not supported. Reviewers: kristof.beyls, rengolin, peter.smith, t.p.northover Reviewed By: peter.smith Subscribers: javed.absar, eraman, cfe-commits, srhines Differential Revision: https://reviews.llvm.org/D44815 llvm-svn: 328829
* [analyzer] Path-insensitive checker for writes into an auto-releasing pointerGeorge Karpenkov2018-03-291-0/+171
| | | | | | | | | | from the wrong auto-releasing pool, as such writes may crash. rdar://25301111 Differential Revision: https://reviews.llvm.org/D44722 llvm-svn: 328827
* Mark __cfi_check as dso_local.Rafael Espindola2018-03-291-0/+3
| | | | llvm-svn: 328825
* Generalize NRVO to cover C structs.Akira Hatanaka2018-03-2911-805/+433
| | | | | | | | | | | This commit generalizes NRVO to cover C structs (both trivial and non-trivial structs). rdar://problem/33599681 Differential Revision: https://reviews.llvm.org/D44968 llvm-svn: 328809
* [Sema] Make deprecation fix-it replace all multi-parameter ObjC method slots.Volodymyr Sapsai2018-03-291-0/+177
| | | | | | | | | | | | | | | | | | Deprecation replacement can be any text but if it looks like a name of ObjC method and has the same number of arguments as original method, replace all slot names so after applying a fix-it you have valid code. rdar://problem/36660853 Reviewers: aaron.ballman, erik.pilkington, rsmith Reviewed By: erik.pilkington Subscribers: cfe-commits, jkorous-apple Differential Revision: https://reviews.llvm.org/D44589 llvm-svn: 328807
* Set dso_local when clearing dllimport.Rafael Espindola2018-03-291-0/+2
| | | | llvm-svn: 328801
* Add a dllimport test.Rafael Espindola2018-03-291-0/+7
| | | | | | Thanks to rnk for the suggestion. llvm-svn: 328800
* [test] Fix an XRay test on FreeBSDZhihao Yuan2018-03-291-1/+1
| | | | | | | | | | | | Summary: Fixing clang-test on FreeBSD as a follow-up of https://reviews.llvm.org/D43378 to handle the revert happened in r325749. Reviewers: devnexen, krytarowski, dberris Subscribers: emaste, dberris, cfe-commits Differential Revision: https://reviews.llvm.org/D45002 llvm-svn: 328797
* Set calling convention for CUDA kernelYaxun Liu2018-03-291-0/+29
| | | | | | | | | | | This patch sets target specific calling convention for CUDA kernels in IR. Patch by Greg Rodgers. Revised and lit test added by Yaxun Liu. Differential Revision: https://reviews.llvm.org/D44747 llvm-svn: 328795
* Disable emitting static extern C aliases for amdgcn target for CUDAYaxun Liu2018-03-291-0/+3
| | | | | | | | | Patch by Greg Rodgers. Revised and lit test added by Yaxun Liu. Differential Revision: https://reviews.llvm.org/D44987 llvm-svn: 328793
* Fix typoMatt Arsenault2018-03-291-1/+1
| | | | llvm-svn: 328791
* [Hexagon] Aid bit-reverse load intrinsics lowering with bitcodeKrzysztof Parzyszek2018-03-293-12/+112
| | | | | | | | | | | The conversion of operatios to bitcode helps to eliminate an additional store in certain cases. We used to lower these load intrinsics in DAG to DAG conversion by which time, the "Dead Store Elimination" pass is already run. There is an associated LLVM patch. Patch by Sumanth Gundapaneni. llvm-svn: 328776
* [ast] Do not auto-initialize Objective-C for-loop variables in Objective-C++ ↵George Karpenkov2018-03-291-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | in templatized code under ARC The AST for the fragment ``` @interface I @end template <typename> void decode(I *p) { for (I *k in p) {} } void decode(I *p) { decode<int>(p); } ``` differs heavily when templatized and non-templatized: ``` |-FunctionTemplateDecl 0x7fbfe0863940 <line:4:1, line:7:1> line:5:6 decode | |-TemplateTypeParmDecl 0x7fbfe0863690 <line:4:11> col:11 typename depth 0 index 0 | |-FunctionDecl 0x7fbfe08638a0 <line:5:1, line:7:1> line:5:6 decode 'void (I *__strong)' | | |-ParmVarDecl 0x7fbfe08637a0 <col:13, col:16> col:16 referenced p 'I *__strong' | | `-CompoundStmt 0x7fbfe0863b88 <col:19, line:7:1> | |   `-ObjCForCollectionStmt 0x7fbfe0863b50 <line:6:3, col:20> | |     |-DeclStmt 0x7fbfe0863a50 <col:8, col:13> | |     | `-VarDecl 0x7fbfe08639f0 <col:8, col:11> col:11 k 'I *const __strong' | |     |-ImplicitCastExpr 0x7fbfe0863a90 <col:16> 'I *' <LValueToRValue> | |     | `-DeclRefExpr 0x7fbfe0863a68 <col:16> 'I *__strong' lvalue ParmVar 0x7fbfe08637a0 'p' 'I *__strong' | |     `-CompoundStmt 0x7fbfe0863b78 <col:19, col:20> | `-FunctionDecl 0x7fbfe0863f80 <line:5:1, line:7:1> line:5:6 used decode 'void (I *__strong)' |   |-TemplateArgument type 'int' |   |-ParmVarDecl 0x7fbfe0863ef8 <col:13, col:16> col:16 used p 'I *__strong' |   `-CompoundStmt 0x7fbfe0890cf0 <col:19, line:7:1> |     `-ObjCForCollectionStmt 0x7fbfe0890cc8 <line:6:3, col:20> |       |-DeclStmt 0x7fbfe0890c70 <col:8, col:13> |       | `-VarDecl 0x7fbfe0890c00 <col:8, col:11> col:11 k 'I *__strong' callinit |       |   `-ImplicitValueInitExpr 0x7fbfe0890c60 <<invalid sloc>> 'I *__strong' |       |-ImplicitCastExpr 0x7fbfe0890cb0 <col:16> 'I *' <LValueToRValue> |       | `-DeclRefExpr 0x7fbfe0890c88 <col:16> 'I *__strong' lvalue ParmVar 0x7fbfe0863ef8 'p' 'I *__strong' |       `-CompoundStmt 0x7fbfe0863b78 <col:19, col:20> ``` Note how in the instantiated version ImplicitValueInitExpr unexpectedly appears. While objects are auto-initialized under ARC, it does not make sense to have an initializer for a for-loop variable, and it makes even less sense to have such a different AST for instantiated and non-instantiated version. Digging deeper, I have found that there are two separate Sema* files for dealing with templates and for dealing with non-templatized code. In a non-templatized version, an initialization was performed only for variables which are not loop variables for an Objective-C loop and not variables for a C++ for-in loop: ```   if (FRI && (Tok.is(tok::colon) || isTokIdentifier_in())) {     bool IsForRangeLoop = false;     if (TryConsumeToken(tok::colon, FRI->ColonLoc)) {       IsForRangeLoop = true;       if (Tok.is(tok::l_brace))         FRI->RangeExpr = ParseBraceInitializer();       else         FRI->RangeExpr = ParseExpression();     }     Decl *ThisDecl = Actions.ActOnDeclarator(getCurScope(), D);     if (IsForRangeLoop)       Actions.ActOnCXXForRangeDecl(ThisDecl);     Actions.FinalizeDeclaration(ThisDecl);     D.complete(ThisDecl);     return Actions.FinalizeDeclaratorGroup(getCurScope(), DS, ThisDecl);   }   SmallVector<Decl *, 8> DeclsInGroup;   Decl *FirstDecl = ParseDeclarationAfterDeclaratorAndAttributes(       D, ParsedTemplateInfo(), FRI); ``` However the code in SemaTemplateInstantiateDecl was inconsistent, guarding only against C++ for-in loops. rdar://38391075 Differential Revision: https://reviews.llvm.org/D44989 llvm-svn: 328749
* [ObjC++] Make parameter passing and function return compatible with ObjCAkira Hatanaka2018-03-284-8/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ObjC and ObjC++ pass non-trivial structs in a way that is incompatible with each other. For example: typedef struct { id f0; __weak id f1; } S; // this code is compiled in c++. extern "C" { void foo(S s); } void caller() { // the caller passes the parameter indirectly and destructs it. foo(S()); } // this function is compiled in c. // 'a' is passed directly and is destructed in the callee. void foo(S a) { } This patch fixes the incompatibility by passing and returning structs with __strong or weak fields using the C ABI in C++ mode. __strong and __weak fields in a struct do not cause the struct to be destructed in the caller and __strong fields do not cause the struct to be passed indirectly. Also, this patch fixes the microsoft ABI bug mentioned here: https://reviews.llvm.org/D41039?id=128767#inline-364710 rdar://problem/38887866 Differential Revision: https://reviews.llvm.org/D44908 llvm-svn: 328731
* [Hexagon] Add support for "new" circular buffer intrinsicsKrzysztof Parzyszek2018-03-281-0/+156
| | | | | | | | | | | | | These instructions have been around for a long time, but we haven't supported intrinsics for them. The "new" vesrions use the CSx register for the start of the buffer instead of the K field in the Mx register. There is a related llvm patch. Patch by Brendon Cahoon. llvm-svn: 328725
* [MS] Fix bug in method vfptr location codeReid Kleckner2018-03-281-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We were assuming that vbtable indices were assigned in layout order in our comparison, which is not the case. When a virtual method, such as the destructor, appears in multiple vftables, the vftable that appears first in object layout order is the one that points to the main implementation of that method. The later vftables use thunks. In this layout, we adjusted "this" in the main implementation by the amount that is appropriate for 'B' instead of 'A', even though the main implementation is found in D's vftable for A: struct A { virtual ~A() {} }; struct B { virtual ~B() {} }; struct C : virtual B {}; struct D : virtual A, C {}; D's layout looks like: 0 D subobject (empty) 0 C base suboject 8 A base subobject 16 B base subobject With this fix, we correctly adjust by -8 in D's deleting destructor instead of -16. Fixes PR36921. llvm-svn: 328723
* [Diag] Avoid emitting a redefinition note if no location is available.Matt Davis2018-03-281-0/+1
| | | | | | | | | | | | | | | | | Summary: The "previous definition is here" note is not helpful if there is no location information. The note will reference nothing in such a case. This patch first checks to see if there is location data, and if so the note diagnostic is emitted. This fixes PR15409. The issue in the first comment seems to already be resolved. This patch addresses the second example. Reviewers: bruno, rsmith Reviewed By: bruno Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D44901 llvm-svn: 328712
* [OPENMP] Codegen for ctor|dtor of declare target variables.Alexey Bataev2018-03-281-0/+104
| | | | | | | | When the declare target variables are emitted for the device, constructors|destructors for these variables must emitted and registered by the runtime in the offloading sections. llvm-svn: 328705
* [PATCH] [RISCV] Verify the input value of -march=Shiva Chen2018-03-281-0/+89
| | | | | | | | | | | | | | Summary: This patch doing more check and verify the -march= string and will issue an error if it's a invalid combination. Reviewers: asb, apazos Differential Revision: https://reviews.llvm.org/D44189 Patch by Kito Cheng. llvm-svn: 328690
* Fix some handling of AST nodes with diagnostics.Richard Trieu2018-03-2810-37/+37
| | | | | | | | | The diagnostic system for Clang can already handle many AST nodes. Instead of converting them to strings first, just hand the AST node directly to the diagnostic system and let it handle the output. Minor changes in some diagnostic output. llvm-svn: 328688
* [ObjC] Make C++ triviality type traits available to non-trivial CAkira Hatanaka2018-03-281-0/+25
| | | | | | | | | | | | | | | | | | | | | | structs. r326307 and r327870 made changes that allowed using non-trivial C structs with fields qualified with __strong or __weak. This commit makes the following C++ triviality type traits available to non-trivial C structs: __has_trivial_assign __has_trivial_move_assign __has_trivial_copy __has_trivial_move_constructor __has_trivial_constructor __has_trivial_destructor rdar://problem/33599681 Differential Revision: https://reviews.llvm.org/D44913 llvm-svn: 328680
* [Sema] Emit -Winteger-overflow for arguments in function calls, ObjC messages.Volodymyr Sapsai2018-03-273-0/+48
| | | | | | | | | | | | | | rdar://problem/35539384 Reviewers: ahatanak, nicholas, rsmith, jkorous-apple Reviewed By: jkorous-apple Subscribers: cfe-commits, jkorous-apple Differential Revision: https://reviews.llvm.org/D42938 llvm-svn: 328671
* [coroutines] Do not attempt to typo-correct when coroutine is looking for ↵Gor Nishanov2018-03-271-4/+21
| | | | | | | | | | required members When SemaCoroutine looks for await_resume, it means it. No need for helpful: "Did you mean await_ready?" messages. Fixes PR33477 and a couple of FIXMEs in test/SemaCXX/coroutines.cpp llvm-svn: 328663
* AMDGPU: Update datalayout for stack alignmentMatt Arsenault2018-03-272-5/+5
| | | | llvm-svn: 328657
* [Sema] Avoid crash for category implementation without interfaceShoaib Meenai2018-03-271-0/+9
| | | | | | | | | | | When we have a category implementation without a corresponding interface (which is an error by itself), semantic checks for property accesses will attempt to access a null interface declaration and then segfault. Error out in such cases instead. Differential Revision: https://reviews.llvm.org/D44916 llvm-svn: 328654
* Update test after r328635 in LLVMKrzysztof Parzyszek2018-03-271-3/+3
| | | | llvm-svn: 328641
* [analyzer] LoopUnrolling: update the matched assignment operatorsPeter Szecsi2018-03-271-11/+99
| | | | | | | | | Extended the matched assignment operators when checking for bound changes in a body of the loop by using the freshly added isAssignmentOperator matcher. This covers all the (current) possible assignments, tests added as well. Differential Revision: https://reviews.llvm.org/D38921 llvm-svn: 328619
* [coroutines] Fix unused warning on result of co_yield.Eric Fiselier2018-03-271-2/+19
| | | | | | | This patch follows up on r328602, which fixed the spurious unused result warning for `co_await`. llvm-svn: 328607
* [coroutines] Fix invalid source range in co_await call expressions.Eric Fiselier2018-03-271-0/+33
| | | | | | | | | | | | | | | | | Summary: Currently an invalid source range is generated for the member call expressions of `co_await`. The end location of the call expression is the `co_await` token loc, while the start is the location of the operand. This causes crashes when the source range is used to produce diagnostics. This patch fixes the issues by using the expression location instead of the token location when building the member calls. Reviewers: GorNishanov, rsmith, vsk, aaron.ballman Reviewed By: vsk Subscribers: cfe-commits, modocache Differential Revision: https://reviews.llvm.org/D44915 llvm-svn: 328606
* Fix unused expression warning in co_await.Eric Fiselier2018-03-271-1/+25
| | | | | | | | | Previously, anytime the result of the resume expression in operator co_await was unused, a warning was generated. This patch fixes the issue by only generating the unused result warning if calling `await_resume()` would also generate a warning. llvm-svn: 328602
OpenPOWER on IntegriCloud