summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaExprCXX.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [AST] Store some data of CXXNewExpr as trailing objectsBruno Ricci2019-01-071-5/+5
| | | | | | | | | | | | | | | | | Store the optional array size expression, optional initialization expression and optional placement new arguments in a trailing array. Additionally store the range for the parenthesized type-id in a trailing object if needed since in the vast majority of cases the type is not parenthesized (not a single new expression in the translation unit of SemaDecl.cpp has a parenthesized type-id). This saves 2 pointers per CXXNewExpr in all cases, and 2 pointers + 8 bytes per CXXNewExpr in the common case where the type is not parenthesized. Differential Revision: https://reviews.llvm.org/D56134 Reviewed By: rjmccall llvm-svn: 350527
* Refactor the way we handle diagnosing unused expression results.Aaron Ballman2019-01-041-0/+2
| | | | | | | | Rather than sprinkle calls to DiagnoseUnusedExprResult() around in places where we want diagnostics, we now diagnose unused expression statements and full expressions in a more generic way when acting on the final expression statement. This results in more appropriate diagnostics for [[nodiscard]] where we were previously lacking them, such as when the body of a for loop is not a compound statement. This patch fixes PR39837. llvm-svn: 350404
* [AST] Store the callee and argument expressions of CallExpr in a trailing array.Bruno Ricci2018-12-211-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since CallExpr::setNumArgs has been removed, it is now possible to store the callee expression and the argument expressions of CallExpr in a trailing array. This saves one pointer per CallExpr, CXXOperatorCallExpr, CXXMemberCallExpr, CUDAKernelCallExpr and UserDefinedLiteral. Given that CallExpr is used as a base of the above classes we cannot use llvm::TrailingObjects. Instead we store the offset in bytes from the this pointer to the start of the trailing objects and manually do the casts + arithmetic. Some notes: 1.) I did not try to fit the number of arguments in the bit-fields of Stmt. This leaves some space for future additions and avoid the discussion about whether x bits are sufficient to hold the number of arguments. 2.) It would be perfectly possible to recompute the offset to the trailing objects before accessing the trailing objects. However the trailing objects are frequently accessed and benchmarks show that it is slightly faster to just load the offset from the bit-fields. Additionally, because of 1), we have plenty of space in the bit-fields of Stmt. Differential Revision: https://reviews.llvm.org/D55771 Reviewed By: rjmccall llvm-svn: 349910
* [Sema] Produce diagnostics when C++17 aligned allocation/deallocationAkira Hatanaka2018-12-211-20/+25
| | | | | | | | | | | functions that are unavailable on Darwin are explicitly called or called from deleting destructors. rdar://problem/40736230 Differential Revision: https://reviews.llvm.org/D47757 llvm-svn: 349890
* [OpenCL] Add generic AS to 'this' pointerMikael Nilsson2018-12-131-6/+5
| | | | | | | | | | | | | Address spaces are cast into generic before invoking the constructor. Added support for a trailing Qualifiers object in FunctionProtoType. Note: This recommits the previously reverted patch, but now it is commited together with a fix for lldb. Differential Revision: https://reviews.llvm.org/D54862 llvm-svn: 349019
* Revert "[OpenCL] Add generic AS to 'this' pointer"Mikael Nilsson2018-12-121-5/+6
| | | | | | Reverting because the patch broke lldb. llvm-svn: 348931
* [OpenCL] Add generic AS to 'this' pointerMikael Nilsson2018-12-121-6/+5
| | | | | | | | | | Address spaces are cast into generic before invoking the constructor. Added support for a trailing Qualifiers object in FunctionProtoType. Differential Revision: https://reviews.llvm.org/D54862 llvm-svn: 348927
* [Sema] Provide -fvisibility-global-new-delete-hidden optionPetr Hosek2018-12-041-3/+4
| | | | | | | | | | | | | | | | | | | | | | | When the global new and delete operators aren't declared, Clang provides and implicit declaration, but this declaration currently always uses the default visibility. This is a problem when the C++ library itself is being built with non-default visibility because the implicit declaration will force the new and delete operators to have the default visibility unlike the rest of the library. The existing workaround is to use assembly to enforce the visiblity: https://fuchsia.googlesource.com/zircon/+/master/system/ulib/zxcpp/new.cpp#108 but that solution is not always available, e.g. in the case of of libFuzzer which is using an internal version of libc++ that's also built with -fvisibility=hidden where the existing behavior is causing issues. This change introduces a new option -fvisibility-global-new-delete-hidden which makes the implicit declaration of the global new and delete operators hidden. Differential Revision: https://reviews.llvm.org/D53787 llvm-svn: 348234
* [OpenCL] Enable address spaces for references in C++Anastasia Stulova2018-11-161-4/+18
| | | | | | | | | | | | | Added references to the addr spaces deduction and enabled CL2.0 features (program scope variables and storage class qualifiers) to work in C++ mode too. Fixed several address space conversion issues in CodeGen for references. Differential Revision: https://reviews.llvm.org/D53764 llvm-svn: 347059
* Revert "[SemaCXX] Unconfuse Clang when std::align_val_t is unscoped in C++03"Eric Fiselier2018-10-251-5/+2
| | | | | | This reverts commit b5d8d0de744d2c212bdb17d5c5fd4447dd14dbd2. llvm-svn: 345306
* [SemaCXX] Unconfuse Clang when std::align_val_t is unscoped in C++03Eric Fiselier2018-10-251-2/+5
| | | | | | | | | | | | | | | | | | | | Summary: When -faligned-allocation is specified in C++03 libc++ defines std::align_val_t as an unscoped enumeration type (because Clang didn't provide scoped enumerations as an extension until 8.0). Unfortunately Clang confuses the `align_val_t` overloads of delete with the sized deallocation overloads which aren't enabled. This caused Clang to call the aligned deallocation function as if it were the sized deallocation overload. For example: https://godbolt.org/z/xXJELh This patch fixes the confusion. Reviewers: rsmith, EricWF Reviewed By: EricWF Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D53508 llvm-svn: 345296
* Revert "[SemaCXX] Unconfuse Clang when std::align_val_t is unscoped in C++03"Eric Fiselier2018-10-241-3/+2
| | | | | | This reverts commit 6f47cdd51341344c0e32630e19e72c94cd25f34e. llvm-svn: 345225
* [SemaCXX] Unconfuse Clang when std::align_val_t is unscoped in C++03Eric Fiselier2018-10-241-2/+3
| | | | | | | | | | | | | | | | | | | | Summary: When -faligned-allocation is specified in C++03 libc++ defines std::align_val_t as an unscoped enumeration type (because Clang didn't provide scoped enumerations as an extension until 8.0). Unfortunately Clang confuses the `align_val_t` overloads of delete with the sized deallocation overloads which aren't enabled. This caused Clang to call the aligned deallocation function as if it were the sized deallocation overload. For example: https://godbolt.org/z/xXJELh This patch fixes the confusion. Reviewers: rsmith, EricWF Reviewed By: EricWF Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D53508 llvm-svn: 345211
* [OpenCL][NFC] Unify ZeroToOCL* cast typesAndrew Savonichev2018-10-231-6/+1
| | | | | | | | | | | | Reviewers: Anastasia, yaxunl Reviewed By: Anastasia Subscribers: asavonic, cfe-commits Differential Revision: https://reviews.llvm.org/D52654 llvm-svn: 345038
* PR24164, PR39336: init-captures are not distinct full-expressions.Richard Smith2018-10-191-27/+10
| | | | | | | | | Rather, they are subexpressions of the enclosing lambda-expression, and any temporaries in them are destroyed at the end of that full-expression, or when the corresponding lambda-expression is destroyed if they are lifetime-extended. llvm-svn: 344801
* [CUDA] Ignore uncallable functions when we check for usual deallocators.Artem Belevich2018-09-211-1/+23
| | | | | | | | | Previously clang considered function variants from both sides of compilation and that resulted in picking up wrong deallocation function. Differential Revision: https://reviews.llvm.org/D51808 llvm-svn: 342749
* [clang][NFC] Fix typo in the name of a noteLouis Dionne2018-08-211-1/+1
| | | | | | | | | | | | | | Summary: r306722 introduced a new note called note_silence_unligned_allocation_unavailable where I believe what was meant is note_silence_aligned_allocation_unavailable. Reviewers: ahatanak Subscribers: dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D51043 llvm-svn: 340288
* Port getLocEnd -> getEndLocStephen Kelly2018-08-091-16/+9
| | | | | | | | | | Reviewers: teemperor! Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D50351 llvm-svn: 339386
* Port getLocStart -> getBeginLocStephen Kelly2018-08-091-82/+73
| | | | | | | | | | Reviewers: teemperor! Subscribers: jholewinski, whisperity, jfb, cfe-commits Differential Revision: https://reviews.llvm.org/D50350 llvm-svn: 339385
* PR38286: Don't crash when attempting to define a constructor for anRichard Smith2018-08-081-2/+8
| | | | | | incomplete class template. llvm-svn: 339210
* [Preprocessor] Allow libc++ to detect when aligned allocation is unavailable.Volodymyr Sapsai2018-08-031-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Libc++ needs to know when aligned allocation is supported by clang, but is otherwise unavailable at link time. Otherwise, libc++ will incorrectly end up generating calls to `__builtin_operator_new`/`__builtin_operator_delete` with alignment arguments. This patch implements the following changes: * The `__cpp_aligned_new` feature test macro to no longer be defined when aligned allocation is otherwise enabled but unavailable. * The Darwin driver no longer passes `-faligned-alloc-unavailable` when the user manually specifies `-faligned-allocation` or `-fno-aligned-allocation`. * Instead of a warning Clang now generates a hard error when an aligned allocation or deallocation function is referenced but unavailable. Patch by Eric Fiselier. Reviewers: rsmith, vsapsai, erik.pilkington, ahatanak, dexonsmith Reviewed By: rsmith Subscribers: Quuxplusone, cfe-commits Differential Revision: https://reviews.llvm.org/D45015 llvm-svn: 338934
* Add missing temporary materialization conversion on left-hand side of .Richard Smith2018-07-271-12/+13
| | | | | | | | | in some member function calls. Specifically, when calling a conversion function, we would fail to create the AST node representing materialization of the class object. llvm-svn: 338135
* Change \t to spacesFangrui Song2018-07-201-4/+4
| | | | llvm-svn: 337530
* Restructure checking for, and warning on, lifetime extension.Richard Smith2018-07-171-7/+0
| | | | | | | | | | | | | This change implements C++ DR1696, which makes initialization of a reference member of a class from a temporary object ill-formed. The standard wording here is imprecise, but we interpret it as meaning that any time a mem-initializer would result in lifetime extension, the program is ill-formed. This reinstates r337226, reverted in r337255, with a fix for the InitializedEntity alignment problem that was breaking ARM buildbots. llvm-svn: 337329
* Temporarily revert r337226 "Restructure checking for, and warning on, ↵Florian Hahn2018-07-171-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | lifetime extension." This change breaks on ARM because pointers to clang::InitializedEntity are only 4 byte aligned and do not have 3 bits to store values. A possible solution would be to change the fields in clang::InitializedEntity to enforce a bigger alignment requirement. The error message is llvm/include/llvm/ADT/PointerIntPair.h:132:3: error: static_assert failed "PointerIntPair with integer size too large for pointer" static_assert(IntBits <= PtrTraits::NumLowBitsAvailable, include/llvm/ADT/PointerIntPair.h:73:13: note: in instantiation of template class 'llvm::PointerIntPairInfo<const clang::InitializedEntity *, 3, llvm::PointerLikeTypeTraits<const clang::InitializedEntity *> >' requested here Value = Info::updateInt(Info::updatePointer(0, PtrVal), llvm/include/llvm/ADT/PointerIntPair.h:51:5: note: in instantiation of member function 'llvm::PointerIntPair<const clang::InitializedEntity *, 3, (anonymous namespace)::LifetimeKind, llvm::PointerLikeTypeTraits<const clang::InitializedEntity *>, llvm::PointerIntPairInfo<const clang::InitializedEntity *, 3, llvm::PointerLikeTypeTraits<const clang::InitializedEntity *> > >::setPointerAndInt' requested here setPointerAndInt(PtrVal, IntVal); ^ llvm/tools/clang/lib/Sema/SemaInit.cpp:6237:12: note: in instantiation of member function 'llvm::PointerIntPair<const clang::InitializedEntity *, 3, (anonymous namespace)::LifetimeKind, llvm::PointerLikeTypeTraits<const clang::InitializedEntity *>, llvm::PointerIntPairInfo<const clang::InitializedEntity *, 3, llvm::PointerLikeTypeTraits<const clang::InitializedEntity *> > >::PointerIntPair' requested here return {Entity, LK_Extended}; Full log here: http://lab.llvm.org:8011/builders/clang-cmake-armv7-global-isel/builds/1330 http://lab.llvm.org:8011/builders/clang-cmake-armv7-full/builds/1394 llvm-svn: 337255
* Restructure checking for, and warning on, lifetime extension.Richard Smith2018-07-171-7/+0
| | | | | | | | | | This change implements C++ DR1696, which makes initialization of a reference member of a class from a temporary object ill-formed. The standard wording here is imprecise, but we interpret it as meaning that any time a mem-initializer would result in lifetime extension, the program is ill-formed. llvm-svn: 337226
* Fix PR34668 - P0704R1 implementation is too permissiveNicolas Lesser2018-07-131-2/+3
| | | | | | | | | | | | | | | | | | | Summary: https://bugs.llvm.org/show_bug.cgi?id=34668 Pretty straightforward. Reviewers: rsmith, Rakete1111 Reviewed By: Rakete1111 Subscribers: Rakete1111, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D38075 llvm-svn: 337017
* [C++17] Disallow lambdas in template parameters (PR33696).Nicolas Lesser2018-07-121-3/+7
| | | | | | | | | | | | | | Summary: This revision disallows lambdas in template parameters, as reported in PR33696. Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D37442 llvm-svn: 336930
* [Sema] Fix crash in getConstructorName.Ilya Biryukov2018-07-041-0/+2
| | | | | | | | | | | | | | | | Summary: Can happen when getConstructorName is called on invalid decls, specifically the ones that do not have the injected class name. Reviewers: bkramer, rsmith Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D48880 llvm-svn: 336244
* DR1687: When overload resolution selects a built-in operator, implicitRichard Smith2018-06-271-1/+11
| | | | | | | | | | | conversions are only applied to operands of class type, and the second standard conversion sequence is not applied. When diagnosing an invalid builtin binary operator, talk about the original types rather than the converted types. If these differ by a user-defined conversion, tell the user what happened. llvm-svn: 335781
* [Sema] Fix infinite typo correction loop.Volodymyr Sapsai2018-06-261-4/+0
| | | | | | | | | | | | | | | | | | | | | | | NumTypos guard value ~0U doesn't prevent from creating new delayed typos. When you create new delayed typos during typo correction, value ~0U wraps around to 0. When NumTypos is 0 we can miss some typos and treat an expression as it can be typo-corrected. But if the expression is still invalid after correction, we can get stuck in infinite loop trying to correct it. Fix by not using value ~0U so that NumTypos correctly reflects the number of typos. rdar://problem/38642201 Reviewers: arphaman, majnemer, rsmith Reviewed By: rsmith Subscribers: rsmith, nicholas, cfe-commits Differential Revision: https://reviews.llvm.org/D47341 llvm-svn: 335638
* Restore pre-r335182 behavior for naming inherited constructors asRichard Smith2018-06-221-1/+10
| | | | | | | | | | | | | | members of dependent contexts. This permits cases where the names before and after the '::' in a dependent inherited constructor using-declaration do not match, but where we can nonetheless tell when parsing the template that a constructor is being named. Under (open) core language DR 2070, such cases will probably be ill-formed, but r335182 does not quite give that result and didn't intend to change this, so restore the old behavior for now. llvm-svn: 335381
* Related to PR37768: improve diagnostics for class name shadowing.Richard Smith2018-06-201-0/+33
| | | | | | | | | | | | Diagnose the name of the class being shadowed by using declarations, and improve the diagnostics for the case where the name of the class is shadowed by a non-static data member in a class with constructors. In the latter case, we now always give the "member with the same name as its class" diagnostic regardless of the relative order of the member and the constructor, rather than giving an inscrutible diagnostic if the constructor appears second. llvm-svn: 335182
* [OpenCL] Support new/delete in SemaSven van Haastregt2018-06-141-2/+19
| | | | | | | | | Reject uses of the default new/delete operators with a diagnostic instead of a crash in OpenCL C++ mode and accept user-defined forms. Differential Revision: https://reviews.llvm.org/D46651 llvm-svn: 334700
* [OpenCL] Restrict various keywords in OpenCL C++ modeSven van Haastregt2018-05-091-0/+6
| | | | | | | | | | | | | | | | | | | | | | | Restrict the following keywords in the OpenCL C++ language mode, according to Sections 2.2 & 2.9 of the OpenCL C++ 1.0 Specification. - dynamic_cast - typeid - register (already restricted in OpenCL C, update the diagnostic) - thread_local - exceptions (try/catch/throw) - access qualifiers read_only, write_only, read_write Support the `__global`, `__local`, `__constant`, `__private`, and `__generic` keywords in OpenCL C++. Leave the unprefixed address space qualifiers such as global available, i.e., do not mark them as reserved keywords in OpenCL C++. libclcxx provides explicit address space pointer classes such as `global_ptr` and `global<T>` that are implemented using the `__`-prefixed qualifiers. Differential Revision: https://reviews.llvm.org/D46022 llvm-svn: 331874
* Remove \brief commands from doxygen comments.Adrian Prantl2018-05-091-29/+29
| | | | | | | | | | | | | | | | | | | This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
* Track the result of evaluating a computed noexcept specification on theRichard Smith2018-05-031-14/+12
| | | | | | | | | | | | | | FunctionProtoType. We previously re-evaluated the expression each time we wanted to know whether the type is noexcept or not. We now evaluate the expression exactly once. This is not quite "no functional change": it fixes a crasher bug during AST deserialization where we would try to evaluate the noexcept specification in a situation where we have not deserialized sufficient portions of the AST to permit such evaluation. llvm-svn: 331428
* [OPENMP] Enable c++ exceptions outside of the target constructs iff they areAlexey Bataev2018-05-021-1/+5
| | | | | | | | | | enabled for the host. If the compilation for the host enables C++ exceptions, but they are not supported by the device, we still need to allow the code with the exception handling constructs outside of the target regions. llvm-svn: 331372
* Revert "[ObjC] Make C++ triviality type traits available to non-trivial C"Akira Hatanaka2018-04-091-26/+4
| | | | | | | | | | | | | This reverts commit r329289. It was decided that we shouldn't expose the __has_* traits to C since they are deprecated and useless. See the discussion here: http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180402/thread.html#223921 llvm-svn: 329608
* Fix typos in clangAlexander Kornienko2018-04-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Found via codespell -q 3 -I ../clang-whitelist.txt Where whitelist consists of: archtype cas classs checkk compres definit frome iff inteval ith lod methode nd optin ot pres statics te thru Patch by luzpaz! (This is a subset of D44188 that applies cleanly with a few files that have dubious fixes reverted.) Differential revision: https://reviews.llvm.org/D44188 llvm-svn: 329399
* [ObjC] Make C++ triviality type traits available to non-trivial CAkira Hatanaka2018-04-051-4/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | 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 This reapplies r328680. This commit fixes a bug where the copy/move __has_trivial_* traits would return false when a volatile type was being passed. Thanks to Richard Smith for pointing out the mistake. rdar://problem/33599681 Differential Revision: https://reviews.llvm.org/D44913 llvm-svn: 329289
* Revert r328680 ("[ObjC] Make C++ triviality type traits available to ↵Richard Smith2018-04-051-12/+0
| | | | | | | | | non-trivial C structs.") It unintentionally caused the values of the __has_* type traits to change in C++ for trivially-copyable classes with volatile members. llvm-svn: 329247
* [Coroutines] Find custom allocators in class scopeBrian Gesiak2018-04-011-11/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [ObjC] Make C++ triviality type traits available to non-trivial CAkira Hatanaka2018-03-281-0/+12
| | | | | | | | | | | | | | | | | | | | | | 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
* [Builtins] Overload __builtin_operator_new/delete to allow forwarding to ↵Eric Fiselier2018-03-211-2/+123
| | | | | | | | | | | | | | | | | | | | | | | | | | usual allocation/deallocation functions. Summary: Libc++'s default allocator uses `__builtin_operator_new` and `__builtin_operator_delete` in order to allow the calls to new/delete to be ellided. However, libc++ now needs to support over-aligned types in the default allocator. In order to support this without disabling the existing optimization Clang needs to support calling the aligned new overloads from the builtins. See llvm.org/PR22634 for more information about the libc++ bug. This patch changes `__builtin_operator_new`/`__builtin_operator_delete` to call any usual `operator new`/`operator delete` function. It does this by performing overload resolution with the arguments passed to the builtin to determine which allocation function to call. If the selected function is not a usual allocation function a diagnostic is issued. One open issue is if the `align_val_t` overloads should be considered "usual" when `LangOpts::AlignedAllocation` is disabled. In order to allow libc++ to detect this new behavior the value for `__has_builtin(__builtin_operator_new)` has been updated to `201802`. Reviewers: rsmith, majnemer, aaron.ballman, erik.pilkington, bogner, ahatanak Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D43047 llvm-svn: 328134
* Refactoring code around move/copy initialization. NFC.Richard Trieu2018-03-151-1/+1
| | | | | | | | | | | | Use an enum parameter instead of a bool for more control on how the copy elision functions work. Extract the move initialization code from the move or copy initialization block. Patch by: Arthur O'Dwyer Differential Revision: https://reviews.llvm.org/D43898 llvm-svn: 327598
* Re-land "[Sema] Make getCurFunction() return null outside function parsing"Reid Kleckner2018-03-121-10/+8
| | | | | | | | | | | | | | This relands r326965. There was a null dereference in typo correction that was triggered in Sema/diagnose_if.c. We are not always in a function scope when doing typo correction. The fix is to add a null check. LLVM's optimizer made it hard to find this bug. I wrote it up in a not-very-well-editted blog post here: http://qinsb.blogspot.com/2018/03/ub-will-delete-your-null-checks.html llvm-svn: 327334
* Revert "[Sema] Make getCurFunction() return null outside function parsing"Reid Kleckner2018-03-081-8/+10
| | | | | | | | | | This reverts r326965. It seems to have caused repeating test failures in clang/test/Sema/diagnose_if.c on some buildbots. I cannot reproduce the problem, and it's not immediately obvious what the problem is, so let's revert to green. llvm-svn: 326974
* [Sema] Make getCurFunction() return null outside function parsingReid Kleckner2018-03-081-10/+8
| | | | | | | | | | | | | | | | | | | | | | | | Summary: Before this patch, Sema pre-allocated a FunctionScopeInfo and kept it in the first, always present element of the FunctionScopes stack. This meant that Sema::getCurFunction would return a pointer to this pre-allocated object when parsing code outside a function body. This is pretty much always a bug, so this patch moves the pre-allocated object into a separate unique_ptr. This should make bugs like PR36536 a lot more obvious. As you can see from this patch, there were a number of places that unconditionally assumed they were always called inside a function. However, there are also many places that null checked the result of getCurFunction(), so I think this is a reasonable direction. Reviewers: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D44039 llvm-svn: 326965
* Remove redundant casts. NFCGeorge Burgess IV2018-03-011-2/+1
| | | | | | | | | | | | | | | | | | | So I wrote a clang-tidy check to lint out redundant `isa`, `cast`, and `dyn_cast`s for fun. This is a portion of what it found for clang; I plan to do similar cleanups in LLVM and other subprojects when I find time. Because of the volume of changes, I explicitly avoided making any change that wasn't highly local and obviously correct to me (e.g. we still have a number of foo(cast<Bar>(baz)) that I didn't touch, since overloading is a thing and the cast<Bar> did actually change the type -- just up the class hierarchy). I also tried to leave the types we were cast<>ing to somewhere nearby, in cases where it wasn't locally obvious what we were dealing with before. llvm-svn: 326416
OpenPOWER on IntegriCloud