summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaExprCXX.cpp
Commit message (Collapse)AuthorAgeFilesLines
* 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
* [Sema] Toggle diags when finding allocators (NFCI)Brian Gesiak2018-02-151-42/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Many methods in Sema take a `bool Diagnose` parameter. Examples of such methods include `Sema::FindDeallocationFunction` and `Sema::SpecialMemberIsTrivial`. Calling these methods with `Diagnose = false` allows callers to, for instance, check for the existence of a deallocation function, without that check resulting in error diagnostics being emitted if no matching deallocation function exists. Add a similar `bool Diagnose` to the `Sema::FindAllocationFunctions` method, so that checks for the existence of allocation functions can be made without triggering error diagnostics. This allows `SemaCoroutine.cpp`, in its implementation of the Coroutines TS, to check for the existence of a particular `operator new` overload, but then without error fall back to a default `operator new` if no matching overload exists. Test Plan: `check-clang` Reviewers: rsmith, GorNishanov, eric_niebler Reviewed By: GorNishanov Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D42605 llvm-svn: 325288
* [Parse] Forward brace locations to TypeConstructExprVedant Kumar2018-01-171-22/+36
| | | | | | | | | | | | | | | | | | | | | | | | When parsing C++ type construction expressions with list initialization, forward the locations of the braces to Sema. Without these locations, the code coverage pass crashes on the given test case, because the pass relies on getLocEnd() returning a valid location. Here is what this patch does in more detail: - Forwards init-list brace locations to Sema (ParseExprCXX), - Builds an InitializationKind with these locations (SemaExprCXX), and - Uses these locations for constructor initialization (SemaInit). The remaining changes fall out of introducing a new overload for creating direct-list InitializationKinds. Testing: check-clang, and a stage2 coverage-enabled build of clang with asserts enabled. Differential Revision: https://reviews.llvm.org/D41921 llvm-svn: 322729
* Add `__reference_binds_to_temporary` trait for checking safe reference ↵Eric Fiselier2018-01-121-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | initialization. Summary: The STL types `std::pair` and `std::tuple` can both store reference types. However their constructors cannot adequately check if the initialization of reference types is safe. For example: ``` std::tuple<std::tuple<int> const&> t = 42; // The stored reference is already dangling. ``` Libc++ has a best effort attempts in tuple to diagnose this, but they're not able to handle all valid cases (If I'm not mistaken). For example initialization of a reference from the result of a class's conversion operator. Libc++ would benefit from having a builtin traits which can provide a much better implementation. This patch introduce the `__reference_binds_to_temporary(T, U)` trait that determines whether a reference of type `T` bound to an expression of type `U` would bind to a materialized temporary object. Note that the trait simply returns false if `T` is not a reference type instead of reporting it as an error. ``` static_assert(__is_constructible(int const&, long)); static_assert(__reference_binds_to_temporary(int const&, long)); ``` Reviewers: majnemer, rsmith Reviewed By: rsmith Subscribers: compnerd, cfe-commits Differential Revision: https://reviews.llvm.org/D29930 llvm-svn: 322334
* [NFC] Modernize enum 'UnqualifiedId::IdKind' into a scoped enum ↵Faisal Vali2017-12-301-8/+8
| | | | | | UnqualifiedIdKind. llvm-svn: 321574
* [AST] Inline CompoundStmt contents into the parent allocation.Benjamin Kramer2017-12-241-3/+2
| | | | | | Saves a pointer on every CompoundStmt. llvm-svn: 321429
* Revert a part of 320489 that was submitted unintentionally.Erich Keane2017-12-121-2/+1
| | | | llvm-svn: 320493
* Fix ICE when __has_unqiue_object_representations called with invalid declErich Keane2017-12-121-1/+2
| | | | llvm-svn: 320489
* P0620 follow-up: deducing `auto` from braced-init-list in new exprZhihao Yuan2017-12-111-5/+12
| | | | | | | | | | | | | | | | | | | Summary: This is a side-effect brought in by p0620r0, which allows other placeholder types (derived from `auto` and `decltype(auto)`) to be usable in a `new` expression with a single-clause //braced-init-list// as its initializer (8.3.4 [expr.new]/2). N3922 defined its semantics. References: http://wg21.link/p0620r0 http://wg21.link/n3922 Reviewers: rsmith, aaron.ballman Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D39451 llvm-svn: 320401
* Remove creation of out-of-bounds value of enumeration type (resulting in UB).Richard Smith2017-12-081-2/+2
| | | | | | | Also remove unnecessary initialization of out-parameters with this value, so that MSan is able to catch errors appropriately. llvm-svn: 320212
* P0722R2: The first parameter in an implicit call to a destroying operatorRichard Smith2017-12-051-0/+9
| | | | | | delete should be a cv-unqualified pointer to the deleted object. llvm-svn: 319858
* Now that C++17 is official (https://www.iso.org/standard/68564.html), start ↵Aaron Ballman2017-12-041-1/+1
| | | | | | changing the C++1z terminology over to C++17. NFC intended, these are all mechanical changes. llvm-svn: 319688
* Fix __has_unique_object_representations implementationErich Keane2017-11-301-1/+1
| | | | | | | | | | As rsmith pointed out, the original implementation of this intrinsic missed a number of important situations. This patch fixe a bunch of shortcomings and implementation details to make it work correctly. Differential Revision: https://reviews.llvm.org/D39347 llvm-svn: 319446
* mplement __has_unique_object_representationsErich Keane2017-10-241-0/+3
| | | | | | | | | | | | A helper builtin to facilitate implementing the std::has_unique_object_representations type trait. Requested here: https://bugs.llvm.org/show_bug.cgi?id=34942 Also already exists in GCC and MSVC. Differential Revision: https://reviews.llvm.org/D39064 llvm-svn: 316518
* Make __builtin_types_compatible_p more like GCC'sGeorge Burgess IV2017-10-161-3/+7
| | | | | | | | | | | GCC ignore qualifiers on array types. Since we seem to have this function primarily for GCC compatibility, we should try to match that behavior. This also adds a few more test-cases __builtin_types_compatible_p, which were inspired by GCC's documentation on the builtin. llvm-svn: 315951
* Convert clang::LangAS to a strongly typed enumAlexander Richardson2017-10-151-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Convert clang::LangAS to a strongly typed enum Currently both clang AST address spaces and target specific address spaces are represented as unsigned which can lead to subtle errors if the wrong type is passed. It is especially confusing in the CodeGen files as it is not possible to see what kind of address space should be passed to a function without looking at the implementation. I originally made this change for our LLVM fork for the CHERI architecture where we make extensive use of address spaces to differentiate between capabilities and pointers. When merging the upstream changes I usually run into some test failures or runtime crashes because the wrong kind of address space is passed to a function. By converting the LangAS enum to a C++11 we can catch these errors at compile time. Additionally, it is now obvious from the function signature which kind of address space it expects. I found the following errors while writing this patch: - ItaniumRecordLayoutBuilder::LayoutField was passing a clang AST address space to TargetInfo::getPointer{Width,Align}() - TypePrinter::printAttributedAfter() prints the numeric value of the clang AST address space instead of the target address space. However, this code is not used so I kept the current behaviour - initializeForBlockHeader() in CGBlocks.cpp was passing LangAS::opencl_generic to TargetInfo::getPointer{Width,Align}() - CodeGenFunction::EmitBlockLiteral() was passing a AST address space to TargetInfo::getPointerWidth() - CGOpenMPRuntimeNVPTX::translateParameter() passed a target address space to Qualifiers::addAddressSpace() - CGOpenMPRuntimeNVPTX::getParameterAddress() was using llvm::Type::getPointerTo() with a AST address space - clang_getAddressSpace() returns either a LangAS or a target address space. As this is exposed to C I have kept the current behaviour and added a comment stating that it is probably not correct. Other than this the patch should not cause any functional changes. Reviewers: yaxunl, pcc, bader Reviewed By: yaxunl, bader Subscribers: jlebar, jholewinski, nhaehnle, Anastasia, cfe-commits Differential Revision: https://reviews.llvm.org/D38816 llvm-svn: 315871
* Support for destroying operator delete, per C++2a proposal P0722.Richard Smith2017-10-131-8/+34
| | | | | | | | | | This feature is not (yet) approved by the C++ committee, so this is liable to be reverted or significantly modified based on committee feedback. No functionality change intended for existing code (a new type must be defined in namespace std to take advantage of this feature). llvm-svn: 315662
* Suppress -Wdelete-non-virtual-dtor warnings about classes defined in system ↵Nico Weber2017-08-311-0/+6
| | | | | | | | | | | | | | | | headers. r312167 made it so that we emit Wdelete-non-virtual-dtor from delete statements that are in system headers (e.g. std::unique_ptr). That works great on Linux and macOS, but on Windows there are non-final classes that are defined in system headers that have virtual methods but non-virtual destructors and yet get deleted through a base class pointer (e.g. ATL::CAccessToken::CRevert). So paddle back a bit and don't emit the warning if it's about a class defined in a system header. https://reviews.llvm.org/D37324 llvm-svn: 312216
* Let -Wdelete-non-virtual-dtor fire in system headers too.Nico Weber2017-08-301-1/+1
| | | | | | | | | | | | | Makes the warning useful again in a std::unique_ptr world, PR28460. Also make the warning not fire in unevaluated contexts, since system libraries (e.g. libc++) do do that. This would've been a good change before we started emitting this warning in system headers too, but "normal" code seems to be less template-heavy, so we didn't notice until now. https://reviews.llvm.org/D37235 llvm-svn: 312167
* [c++2a] P0704R1: Allow pointers to const& member functions to be called on ↵Richard Smith2017-08-251-3/+10
| | | | | | | | rvalues. Patch by Blitz Rakete! llvm-svn: 311744
* Allow operator delete to be an invalid Decl.Richard Trieu2017-08-091-3/+0
| | | | | | | | Do not discard invalid Decl when searching for the operator delete function. The lookup for this function always expects to find a result, so sometimes the invalid Decl is the only choice possible. This fixes PR34109. llvm-svn: 310435
* [Sema] Improve diagnostic message for unavailable C++17 alignedAkira Hatanaka2017-07-191-2/+7
| | | | | | | | | | | | | | | | | | allocation functions. This changes the error message Sema prints when an unavailable C++17 aligned allocation function is selected. Original message: "... possibly unavailable on x86_64-apple-macos10.12" New message: "... only available on macOS 10.13 or newer" This is a follow-up to r306722. rdar://problem/32664169 Differential Revision: https://reviews.llvm.org/D35520 llvm-svn: 308496
* [Sema] Issue diagnostics if a new/delete expression generates a call toAkira Hatanaka2017-06-291-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | a c++17 aligned allocation/deallocation function that is unavailable in the standard library on Apple platforms. The aligned functions are implemented only in the following versions or later versions of the OSes, so clang issues diagnostics if the deployment target being targeted is older than these: macosx: 10.13 ios: 11.0 tvos: 11.0 watchos: 4.0 The diagnostics are issued whenever the aligned functions are selected except when the selected function has a definition in the same file. If there is a user-defined function available somewhere else, option -Wno-aligned-allocation-unavailable can be used to silence the diagnostics. rdar://problem/32664169 Differential Revision: https://reviews.llvm.org/D34574 llvm-svn: 306722
* Fix crash in clang while handling __has_trivial_destructor.Karthik Bhat2017-06-281-9/+11
| | | | | | | | | Fix crash in clang when an array of unknown bounds of an incomplete type is passed to __has_trivial_destructor. Patch by Puneetha https://reviews.llvm.org/D34198 llvm-svn: 306519
* PR33552: Distinguish between declarations that are owned by no module andRichard Smith2017-06-231-2/+2
| | | | | | | | | | | | | | | | | | | declarations that are owned but unconditionally visible. This allows us to set declarations as visible even if they have a local owning module, without losing information. In turn, that means that our Objective-C support can keep on incorrectly assuming the "hidden" bit on the declaration is the whole story with regard to name visibility. This will also be useful once we support the C++ Modules TS export semantics. Objective-C name visibility is still incorrect in any case where the "hidden" bit is not the complete story: for instance, in Objective-C++ the set of visible categories will be wrong during template instantiation, and with local submodule visibility enabled it will be wrong when building modules. Fixing that will require a major overhaul of how visibility is handled for Objective-C (and particularly for categories). llvm-svn: 306075
* Don't crash when forming a destructor name on an incomplete type.John McCall2017-06-111-3/+6
| | | | | | | | Fixes PR25156. Patch by Don Hinton! llvm-svn: 305169
* 27037: Use correct CVR qualifier on an upcast on method pointer callRichard Smith2017-06-091-1/+3
| | | | | | | | Patch by Taiju Tsuiki! Differential Revision: https://reviews.llvm.org/D33875 llvm-svn: 305126
* [modules] Fix that global delete operator get's assigned to a submodule.Vassil Vassilev2017-06-091-0/+2
| | | | | | | | | | | | | | | n the current local-submodule-visibility mode, as soon as we discover a virtual destructor, we declare on demand a global delete operator. However, this causes that this delete operator is owned by the submodule which contains said virtual destructor. This means that other modules no longer can see the global delete operator which is hidden inside another submodule and fail to compile. This patch unhides those global allocation function once they're created to prevent this issue. Patch by Raphael Isemann (D33366)! llvm-svn: 305118
* [Sema] Refactor OverloadCandidate::BuiltinTypes. NFC.George Burgess IV2017-06-081-6/+6
| | | | | | As promised in r304996. llvm-svn: 305013
* PR33232: implement support for MSVC's __is_trivially_destructible trait.Richard Smith2017-06-011-17/+16
| | | | | | | | | | | | | | | | | Unlike the GCC-compatible __has_trivial_destructor trait, this one computes the right answer rather than performing the quirky set of checks described in GCC's documentation (https://gcc.gnu.org/onlinedocs/gcc/Type-Traits.html). MSVC also has a __has_trivial_destructor trait which is the same as its (and now Clang's) __is_trivially_destructible trait; we might want to consider changing the behavior of __has_trivial_destructor if we're targeting an MSVC platform, but I'm not doing so for now. While implementing this I found that we were incorrectly rejecting __is_destructible queries on arrays of unknown bound of incomplete types; that too is fixed, and I've added similar tests for other traits for good measure. llvm-svn: 304376
* [Sema] Support implicit scalar to vector conversionsSimon Dardis2017-05-121-0/+9
| | | | | | | | | | | | | | | | | | This patch teaches clang to perform implicit scalar to vector conversions when one of the operands of a binary vector expression is a scalar which can be converted to the element type of the vector without truncation following GCC's implementation. If the (constant) scalar is can be casted safely, it is implicitly casted to the vector elements type and splatted to produce a vector of the same type. Contributions from: Petar Jovanovic Reviewers: bruno, vkalintiris Differential Revision: https://reviews.llvm.org/D25866 llvm-svn: 302935
* [Sema] Objective-C++ support for type trait __is_base_ofErik Pilkington2017-05-101-3/+17
| | | | | | | | rdar://24308607 Differential revision: https://reviews.llvm.org/D32891 llvm-svn: 302695
OpenPOWER on IntegriCloud