summaryrefslogtreecommitdiffstats
path: root/clang/lib
Commit message (Collapse)AuthorAgeFilesLines
* [CodeGen] Emit parallel_loop_access for each loop in the loop stack.Michael Kruse2018-08-031-2/+13
| | | | | | | | | | | | | | | | | Summary: Emit !llvm.mem.parallel_loop_access metadata for memory accesses even if the parallel loop is not the top on the loop stack. Fixes llvm.org/PR37558. Reviewers: ABataev, hfinkel, amusman, tyler.nowicki Reviewed By: hfinkel Subscribers: Meinersbur, hfinkel, cfe-commits Differential Revision: https://reviews.llvm.org/D48808 llvm-svn: 338810
* Sema: Fix explicit address space cast involving void pointersYaxun Liu2018-08-031-7/+14
| | | | | | | | | | | | Explicit cast of a void pointer to a pointer type in different address space is incorrectly classified as bitcast, which causes invalid bitcast in codegen. The patch fixes that by checking the address space of the source and destination type and set the correct cast kind. Differential Revision: https://reviews.llvm.org/D50003 llvm-svn: 338805
* Fold two cast plus a cast in a loop into a variable.Nicolas Lesser2018-08-031-5/+5
| | | | | | This avoids to recast `Record` multiple times. llvm-svn: 338801
* Append new attributes to the end of an AttributeList.Michael Kruse2018-08-037-69/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Recommit of r335084 after revert in r335516. ... instead of prepending it at the beginning (the original behavior since implemented in r122535 2010-12-23). This builds up an AttributeList in the the order in which the attributes appear in the source. The reverse order caused nodes for attributes in the AST (e.g. LoopHint) to be in the reverse order, and therefore printed in the wrong order in -ast-dump. Some TODO comments mention this. The order was explicitly reversed for enable_if attribute overload resolution and name mangling, which is not necessary anymore with this patch. The change unfortunately has some secondary effect, especially on diagnostic output. In the simplest cases, the CHECK lines or expected diagnostic were changed to the the new output. If the kind of error/warning changed, the attributes' order was changed instead. This unfortunately causes some 'previous occurrence here' hints to be textually after the main marker. This typically happens when attributes are merged, but are incompatible to each other. Interchanging the role of the the main and note SourceLocation will also cause the case where two different declaration's attributes (in contrast to multiple attributes of the same declaration) are merged to be reverse. There is no easy fix because sometimes previous attributes are merged into a new declaration's attribute list, sometimes new attributes are added to a previous declaration's attribute list. Since 'previous occurrence here' pointing to locations after the main marker is not rare, I left the markers as-is; it is only relevant when the attributes are declared in the same declaration anyway. Differential Revision: https://reviews.llvm.org/D48100 llvm-svn: 338800
* [modules] Defer merging deduced return types.Richard Smith2018-08-032-20/+58
| | | | | | | | | | | We can't read a deduced return type until we are sure that the types referred to by it are not in the middle of being loaded. So defer all reading of such deduced return types until the end of the recursive deserialization step. Also, when we load a function type that has a deduced return type, update all other redeclarations of the function to have that deduced return type. llvm-svn: 338798
* [analyzer] Detect pointers escaped after ReturnStmt execution in MallocChecker.Reka Kovacs2018-08-021-3/+25
| | | | | | | | | | Objects local to a function are destroyed right after the statement returning (part of) them is executed in the analyzer. This patch enables MallocChecker to warn in these cases. Differential Revision: https://reviews.llvm.org/D49361 llvm-svn: 338780
* [analyzer] Obtain a ReturnStmt from a CFGAutomaticObjDtor.Reka Kovacs2018-08-022-1/+24
| | | | | | | | | | | The CoreEngine only gives us a ReturnStmt if the last element in the CFGBlock is a CFGStmt, otherwise the ReturnStmt is nullptr. This patch adds support for the case when the last element is a CFGAutomaticObjDtor, by returning its TriggerStmt as a ReturnStmt. Differential Revision: https://reviews.llvm.org/D49811 llvm-svn: 338777
* [analyzer] Add a safety check to InnerPointerChecker.Reka Kovacs2018-08-021-2/+5
| | | | | | Do not crash if the CXXRecordDecl of an object is not available. llvm-svn: 338775
* [WebAssembly] Support for atomic.wait / atomic.wake builtinsHeejin Ahn2018-08-021-0/+20
| | | | | | | | | | | | | | Summary: Add support for atomic.wait / atomic.wake builtins based on the Wasm thread proposal. Reviewers: dschuff Subscribers: sbc100, jgravelle-google, sunfish, cfe-commits Differential Revision: https://reviews.llvm.org/D49396 llvm-svn: 338771
* Fix assertion failure when emitting code for a merged lambda.Richard Smith2018-08-021-2/+13
| | | | llvm-svn: 338766
* Work around more GCC miscompiles exposed by r338464.Martin Storsjo2018-08-021-1/+5
| | | | | | | | | This is the same fix as in r338478, for another occurrance of the same pattern from r338464. See gcc.gnu.org/PR86769 for details of the bug. llvm-svn: 338749
* __c11_atomic_load's _Atomic can be constJF Bastien2018-08-021-1/+1
| | | | | | | | | | | | | | | | | | | | | Summary: C++11 onwards specs the non-member functions atomic_load and atomic_load_explicit as taking the atomic<T> by const (potentially volatile) pointer. C11, in its infinite wisdom, decided to drop the const, and C17 will fix this with DR459 (the current draft forgot to fix B.16, but that’s not the normative part). clang’s lib/Headers/stdatomic.h implements these as #define to the __c11_* equivalent, which are builtins with custom typecheck. Fix the typecheck. D47613 takes care of the libc++ side. Discussion: http://lists.llvm.org/pipermail/cfe-dev/2018-May/058129.html <rdar://problem/27426936> Reviewers: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D47618 llvm-svn: 338743
* [analyzer] Make RegionVector use const referenceFangrui Song2018-08-021-10/+7
| | | | llvm-svn: 338732
* Try to make builtin address space declarations not uselessMatt Arsenault2018-08-024-48/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The way address space declarations for builtins currently work is nearly useless. The code assumes the address spaces used for builtins is a confusingly named "target address space" from user code using __attribute__((address_space(N))) that matches the builtin declaration. There's no way to use this to declare a builtin that returns a language specific address space. The terminology used is highly cofusing since it has nothing to do with the the address space selected by the target to use for a language address space. This feature is essentially unused as-is. AMDGPU and NVPTX are the only in-tree targets attempting to use this. The AMDGPU builtins certainly do not behave as intended (i.e. all of the builtins returning pointers can never compile because the numbered address space never matches the expected named address space). The NVPTX builtins are missing tests for some, and the others seem to rely on an implicit addrspacecast. Change the used address space for builtins based on a target hook to allow using a language address space for a builtin. This allows the same builtin declaration to be used for multiple languages with similarly purposed address spaces (e.g. the same AMDGPU builtin can be used in OpenCL and CUDA even though the constant address spaces are arbitarily different). This breaks the possibility of using arbitrary numbered address spaces alongside the named address spaces for builtins. If this is an issue we probably need to introduce another builtin declaration character to distinguish language address spaces from so-called "target address spaces". llvm-svn: 338707
* clang-format: fix a crash in comment wraps.Martin Probst2018-08-021-5/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Previously, clang-format would crash if it tried to wrap an overlong single line comment, because two parts of the code inserted a break in the same location. /** heregoesalongcommentwithnospace */ This wasn't previously noticed as it could only trigger for an overlong single line comment that did have no breaking opportunities except for a whitespace at the very beginning. This also introduces a check for JavaScript to not ever wrap a comment before an opening curly brace: /** @mods {donotbreakbeforethecurly} */ This is because some machinery parsing these tags sometimes supports breaks before a possible `{`, but in some other cases does not. Previously clang-format was careful never to wrap a line with certain tags on it. The better solution is to specifically disable wrapping before the problematic token: this allows wrapping and aligning comments but still avoids the problem. Reviewers: krasimir Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D50177 llvm-svn: 338706
* [analyzer] Extend NoStoreFuncVisitor to follow fields.George Karpenkov2018-08-021-126/+212
| | | | | | | | rdar://39701823 Differential Revision: https://reviews.llvm.org/D49901 llvm-svn: 338667
* Serialize DoesNotEscape.Akira Hatanaka2018-08-012-0/+2
| | | | | | I forgot to commit this in r326530. llvm-svn: 338656
* [AST] Remove the static_assert check in ObjCMethodDecl::ObjCMethodDeclVlad Tsyrklevich2018-08-011-7/+0
| | | | | | | | | | | | | | Summary: This check was introduced by r338641 but this broke some builds. For now remove it. Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D50163 llvm-svn: 338648
* Fix -Wcovered-switch-default uncovered after r338630Reid Kleckner2018-08-011-1/+1
| | | | llvm-svn: 338643
* [AST][4/4] Move the bit-fields from ObjCMethodDecl and ObjCContainerDecl ↵Erich Keane2018-08-014-24/+69
| | | | | | | | | | | | | | | | | into DeclContext This patch follows https://reviews.llvm.org/D49729, https://reviews.llvm.org/D49732 and https://reviews.llvm.org/D49733. Move the bits from ObjCMethodDecl and ObjCContainerDecl into DeclContext. Differential Revision: https://reviews.llvm.org/D49734 Patch By: bricci llvm-svn: 338641
* [AST][3/4] Move the bit-fields from BlockDecl, LinkageSpecDecl and ↵Erich Keane2018-08-013-1/+27
| | | | | | | | | | | | | | | | | OMPDeclareReductionDecl into DeclContext This patch follows https://reviews.llvm.org/D49729 and https://reviews.llvm.org/D49732, and is followed by https://reviews.llvm.org/D49734. Move the bits from BlockDecl, LinkageSpecDecl and OMPDeclareReductionDecl into DeclContext. Differential Revision: https://reviews.llvm.org/D49733 Patch By: bricci llvm-svn: 338639
* [AST][2/4] Move the bit-fields from FunctionDecl and CXXConstructorDecl into ↵Erich Keane2018-08-014-56/+103
| | | | | | | | | | | | | | | | | DeclContext This patch follows https://reviews.llvm.org/D49729 and is followed by https://reviews.llvm.org/D49733 and https://reviews.llvm.org/D49734. Move the bits from FunctionDecl and CXXConstructorDecl into DeclContext. Differential Revision: https://reviews.llvm.org/D49732 Patch By: bricci llvm-svn: 338636
* [AST][1/4] Move the bit-fields from TagDecl, EnumDecl and RecordDecl into ↵Erich Keane2018-08-017-72/+127
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DeclContext DeclContext has a little less than 8 bytes free due to the alignment requirements on 64 bits archs. This set of patches moves the bit-fields from classes deriving from DeclContext into DeclContext. On 32 bits archs this increases the size of DeclContext by 4 bytes but this is balanced by an equal or larger reduction in the size of the classes deriving from it. On 64 bits archs the size of DeclContext stays the same but most of the classes deriving from it shrink by 8/16 bytes. (-print-stats diff here https://reviews.llvm.org/D49728) When doing an -fsyntax-only on all of Boost this result in a 3.6% reduction in the size of all Decls and a 1% reduction in the run time due to the lower cache miss rate. For now CXXRecordDecl is not touched but there is an easy 6 (if I count correctly) bytes gain available there by moving some bits from DefinitionData into the free space of DeclContext. This will be the subject of another patch. This patch sequence also enable the possibility of refactoring FunctionDecl: To save space some bits from classes deriving from FunctionDecl were moved to FunctionDecl. This resulted in a lot of stuff in FunctionDecl which do not belong logically to it. After this set of patches however it is just a simple matter of adding a SomethingDeclBitfields in DeclContext and moving the bits to it from FunctionDecl. This first patch introduces the anonymous union in DeclContext and all the *DeclBitfields classes holding the bit-fields, and moves the bits from TagDecl, EnumDecl and RecordDecl into DeclContext. This patch is followed by https://reviews.llvm.org/D49732, https://reviews.llvm.org/D49733 and https://reviews.llvm.org/D49734. Differential Revision: https://reviews.llvm.org/D49729 Patch By: bricci llvm-svn: 338630
* [Android] Increase default new alignment for AndroidPirama Arumuga Nainar2018-08-011-2/+3
| | | | | | | | | | | | | | Summary: Android's memory allocators also guarantee 8-byte alignment for 32-bit architectures and 16-byte alignment for 64-bit. Reviewers: rsmith Subscribers: cfe-commits, srhines, enh Differential Revision: https://reviews.llvm.org/D50112 llvm-svn: 338603
* Revert r338455 "[constexpr] Support for constant evaluation of ↵Hans Wennborg2018-08-011-198/+48
| | | | | | | | | | | | | | | | __builtin_memcpy and __builtin_memmove (in non-type-punning cases)." It caused asserts during Chromium builds, see reply on the cfe-commits thread. > This is intended to permit libc++ to make std::copy etc constexpr > without sacrificing the optimization that uses memcpy on > trivially-copyable types. > > __builtin_strcpy and __builtin_wcscpy are not handled by this change. > They'd be straightforward to add, but we haven't encountered a need for > them just yet. llvm-svn: 338602
* [Format] Fix for bug 35641Ilya Biryukov2018-08-011-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Bug was caused due to comments at the start of scope. For a code like: ``` int func() { // int b; int c; } ``` the comment at the first line gets IndentAndNestingLevel (1,1) whereas the following declarations get only (0,1) which prevents them from insertion of a new scope. So, I changed the AlignTokenSequence to look at previous *non-comment* token when deciding whether to introduce a new scope into stack or not. Patch by Kadir Cetinkaya! Reviewers: rsmith, djasper Reviewed By: djasper Subscribers: lebedev.ri, cfe-commits, klimek Tags: #clang Differential Revision: https://reviews.llvm.org/D43303 llvm-svn: 338578
* [UnrollAndJam] Add unroll_and_jam pragma handlingDavid Green2018-08-014-28/+140
| | | | | | | | | | | | | | This adds support for the unroll_and_jam pragma, to go with the recently added unroll and jam pass. The name of the pragma is the same as is used in the Intel compiler, and most of the code works the same as for unroll. #pragma clang loop unroll_and_jam has been separated into a different patch. This part adds #pragma unroll_and_jam with an optional count, and #pragma no_unroll_and_jam to disable the transform. Differential Revision: https://reviews.llvm.org/D47267 llvm-svn: 338566
* [AArch64][ARM] Add Armv8.4-A testsSjoerd Meijer2018-08-011-0/+4
| | | | | | | | | This adds tests for Armv8.4-A, and also some v8.2 and v8.3 tests that were missing. Differential Revision: https://reviews.llvm.org/D50068 llvm-svn: 338525
* [clang-format] Add some text proto functions to Google styleKrasimir Georgiev2018-08-011-0/+2
| | | | | | | | | | | | | | Summary: Adds 2 functions taking a text proto argument. Reviewers: djasper, klimek Reviewed By: djasper Subscribers: acoomans, cfe-commits Differential Revision: https://reviews.llvm.org/D50132 llvm-svn: 338524
* wrap to 80 cols, no behavior changeNico Weber2018-08-011-7/+9
| | | | llvm-svn: 338520
* [clang-format] Add @private to the list of jsdoc annotationsKrasimir Georgiev2018-08-011-1/+1
| | | | | | | | | | | | Reviewers: mprobst Reviewed By: mprobst Subscribers: acoomans, cfe-commits Differential Revision: https://reviews.llvm.org/D50138 llvm-svn: 338519
* Add missing semicolon.Simon Pilgrim2018-08-011-1/+1
| | | | llvm-svn: 338510
* Replace 'FALL-THROUGH' comment with LLVM_FALLTHROUGH to silence warning. NFCI.Simon Pilgrim2018-08-011-1/+1
| | | | llvm-svn: 338508
* [Modules] Do not emit relocation error when -fno-validate-pch is setYuka Takahashi2018-08-011-3/+8
| | | | | | | | | | | | Summary: Clang emits error when implicit modules was relocated from the first build directory. However this was biting our usecase where we copy the contents of build directory to another directory in order to distribute. Differential Revision: https://reviews.llvm.org/D49852 llvm-svn: 338503
* [AST] CastExpr: BasePathSize is not large enough.Roman Lebedev2018-08-012-12/+51
| | | | | | | | | | | | | | | | | | | | | | | | Summary: rC337815 / D49508 had to cannibalize one bit of `CastExprBitfields::BasePathSize` in order to squeeze `PartOfExplicitCast` boolean. That reduced the maximal value of `PartOfExplicitCast` from 9 bits (~512) down to 8 bits (~256). Apparently, that mattered. Too bad there weren't any tests. It caused [[ https://bugs.llvm.org/show_bug.cgi?id=38356 | PR38356 ]]. So we need to increase `PartOfExplicitCast` back at least to 9 bits, or a bit more. For obvious reasons, we can't do that in `CastExprBitfields` - that would blow up the size of every `Expr`. So we need to either just add a variable into the `CastExpr` (as done here), or use `llvm::TrailingObjects`. The latter does not seem to be straight-forward. Perhaps, that needs to be done not for the `CastExpr` itself, but for all of it's `final` children. Reviewers: rjmccall, rsmith, erichkeane Reviewed By: rjmccall Subscribers: bricci, hans, cfe-commits, waddlesplash Differential Revision: https://reviews.llvm.org/D50050 llvm-svn: 338489
* Work around GCC miscompile exposed by r338464.Richard Smith2018-08-011-2/+5
| | | | | | See gcc.gnu.org/PR86769 for details of the bug. llvm-svn: 338478
* [analyzer] CallEvent: Add helper methods for obtaining the callee stack frame.Artem Dergachev2018-08-011-0/+63
| | | | | | | | | | | | Newly added methods allow reasoning about the stack frame of the call (as opposed to the stack frame on which the call was made, which was always available) - obtain the stack frame context, obtain parameter regions - even if the call is not going to be (or was not) inlined, i.e. even if the analysis has never actually entered the stack frame. Differential Revision: https://reviews.llvm.org/D49715 llvm-svn: 338474
* Speculative fix for buildbot failures after r338464.Richard Smith2018-08-011-1/+2
| | | | llvm-svn: 338473
* Avoid exposing name for range-based for '__range' variables in lifetime ↵Richard Smith2018-08-011-3/+5
| | | | | | warnings. llvm-svn: 338467
* [P0936R0] add [[clang::lifetimebound]] attributeRichard Smith2018-08-016-75/+223
| | | | | | | | | | | | | | | | | | | This patch adds support for a new attribute, [[clang::lifetimebound]], that indicates that the lifetime of a function result is related to one of the function arguments. When walking an initializer to make sure that the lifetime of the initial value is at least as long as the lifetime of the initialized object, we step through parameters (including the implicit object parameter of a non-static member function) that are marked with this attribute. There's nowhere to write an attribute on the implicit object parameter, so in lieu of that, it may be applied to a function type (where it appears immediately after the cv-qualifiers and ref-qualifier, which is as close to a declaration of the implicit object parameter as we have). I'm currently modeling this in the AST as the attribute appertaining to the function type. Differential Revision: https://reviews.llvm.org/D49922 llvm-svn: 338464
* [constexpr] Support for constant evaluation of __builtin_memcpy andRichard Smith2018-07-311-48/+198
| | | | | | | | | | | | | | __builtin_memmove (in non-type-punning cases). This is intended to permit libc++ to make std::copy etc constexpr without sacrificing the optimization that uses memcpy on trivially-copyable types. __builtin_strcpy and __builtin_wcscpy are not handled by this change. They'd be straightforward to add, but we haven't encountered a need for them just yet. llvm-svn: 338455
* Revert r337635 "[Driver] Sanitizer support based on runtime library presence"Reid Kleckner2018-07-312-65/+23
| | | | | | | | This change causes issues with distributed build systems, which may only have compiler binaries without any runtime libraries. See discussion about this on https://reviews.llvm.org/D15225. llvm-svn: 338444
* [analyzer] Fix eliding the same destructor twice due to buggy default arguments.Artem Dergachev2018-07-311-1/+2
| | | | | | | | | | | Because of incomplete support for CXXDefaultArgExpr, we cannot yet commit to asserting that the same destructor won't be elided twice. Suppress the assertion failure for now. Proper support is still an open problem. Differential Revision: https://reviews.llvm.org/D49213 llvm-svn: 338441
* [CFG] [analyzer] NFC: Enumerate construction context layer kinds.Artem Dergachev2018-07-313-253/+227
| | | | | | | | | | | | | | This is a refactoring patch; no functional change intended. The common part of ConstructionContextLayer and ConstructedObjectKey is factored out into a new structure, ConstructionContextItem. Various sub-kinds of ConstructionContextItem are enumerated in order to provide richer information about construction contexts. Differential Revision: https://reviews.llvm.org/D49210. llvm-svn: 338439
* [serialization] PR34728: Don't assume that only a suffix of templateRichard Smith2018-07-311-15/+9
| | | | | | | | | | | | | parameters can have default arguments. At least for function templates and class template partial specializations, it's possible for a template parameter with a default argument to be followed by a non-pack template parameter with no default argument, and this case was not properly handled here. Testcase by Steve O'Brien! llvm-svn: 338438
* [CFG] [analyzer] Implement function argument construction contexts.Artem Dergachev2018-07-313-28/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | In r330377 and r338425 we have already identified what constitutes function argument constructors and added stubs in order to prevent confusing them with other temporary object constructors. Now we implement a ConstructionContext sub-class to carry all the necessary information about the construction site, namely call expression and argument index. On the analyzer side, the patch interacts with the recently implemented pre-C++17 copy elision support in an interesting manner. If on the CFG side we didn't find a construction context for the elidable constructor, we build the CFG as if the elidable constructor is not elided, and the non-elided constructor within it is a simple temporary. But the same problem may occur in the analyzer: if the elidable constructor has a construction context but the analyzer doesn't implement such context yet, the analyzer should also try to skip copy elision and still inline the non-elided temporary constructor. This was implemented by adding a "roll back" mechanism: when elision fails, roll back the changes and proceed as if it's a simple temporary. The approach is wonky, but i'm fine with that as long as it's merely a defensive mechanism that should eventually go away once all construction contexts become supported. Differential Revision: https://reviews.llvm.org/D48681. llvm-svn: 338436
* [OpenCL] Forbid size dependent types used as kernel argumentsAlexey Sotkin2018-07-311-3/+43
| | | | | | | | | | | | | | | | | | | | Summary: Size_t, intptr_t, uintptr_t and ptrdiff_t cannot be used as kernel arguments, according to OpenCL Specification s6.9k: The size in bytes of these types are implementation-defined and in addition can also be different for the OpenCL device and the host processor making it difficult to allocate buffer objects to be passed as arguments to a kernel declared as pointer to these types. Patch by: Andrew Savonichev Reviewers: Anastasia, yaxunl Subscribers: yaxunl, Anastasia, cfe-commits Differential Revision: https://reviews.llvm.org/D49725 llvm-svn: 338432
* [OpenCL] Check for invalid kernel arguments in array typesAlexey Sotkin2018-07-311-5/+27
| | | | | | | | | | | | | | | | Summary: OpenCL specification forbids use of several types as kernel arguments. This patch improves existing diagnostic to look through arrays. Patch by: Andrew Savonichev Reviewers: Anastasia, yaxunl Subscribers: yaxunl, Anastasia, cfe-commits Differential Revision: https://reviews.llvm.org/D49723 llvm-svn: 338427
* [CFG] [analyzer] Add construction contexts for returning C++ objects in ObjC++.Artem Dergachev2018-07-311-27/+43
| | | | | | | | | | | Like any normal funciton, Objective-C message can return a C++ object in Objective-C++. Such object would require a construction context. This patch, therefore, is an extension of r327343 onto Objective-C++. Differential Revision: https://reviews.llvm.org/D48608 llvm-svn: 338426
* [CFG] [analyzer] Add stubs for constructor and message argument constructors.Artem Dergachev2018-07-312-8/+48
| | | | | | | | | | | | | | | | | | CFG now correctly identifies construction context for temporaries constructed for the purpose of passing into a function as an argument. Such context is still not fully implemented because the information it provides is not rich enough: it doens't contain information about argument index. It will be addresssed later. This patch is an extension of r330377 to C++ construct-expressions and Objective-C message expressions which aren't call-expressions but require similar handling. C++ new-expressions with placement arguments still remain to be handled. Differential Revision: https://reviews.llvm.org/D49826 llvm-svn: 338425
OpenPOWER on IntegriCloud