summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaOverload.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Fix argument numbering confusion when diagnosing a non-viable operator().Richard Smith2019-10-291-2/+4
| | | | | This could lead to crashes if operator() is a variadic template, as we could end up asking for an out-of-bounds argument.
* Revert "[Concepts] Constraint Enforcement & Diagnostics"Vlad Tsyrklevich2019-10-281-47/+0
| | | | | This reverts commit ffa214ef22892d75340dc6720271863901dc2c90, it was causing ASAN test failures on sanitizer-x86_64-linux-bootstrap.
* When diagnosing an ambiguity, only note the candidates that contributeRichard Smith2019-10-241-30/+61
| | | | to the ambiguity, rather than noting all viable candidates.
* [Concepts] Constraint Enforcement & DiagnosticsSaar Raz2019-10-251-0/+47
| | | | | | Part of the C++20 concepts implementation effort. - Associated constraints (requires clauses, currently) are now enforced when instantiating/specializing templates and when considering partial specializations and function overloads. - Elaborated diagnostics give helpful insight as to why the constraints were not satisfied. Phabricator: D41569
* Sema: Create a no-op implicit cast for lvalue function conversions.Peter Collingbourne2019-10-191-14/+19
| | | | | | | | | | This fixes an assertion failure in the case where an implicit conversion for a function call involves an lvalue function conversion, and makes the AST for initializations involving implicit lvalue function conversions more accurate. Differential Revision: https://reviews.llvm.org/D66437 llvm-svn: 375313
* [c++20] Add rewriting from comparison operators to <=> / ==.Richard Smith2019-10-191-107/+370
| | | | | | | | | | | | | | | | | This adds support for rewriting <, >, <=, and >= to a normal or reversed call to operator<=>, for rewriting != to a normal or reversed call to operator==, and for rewriting <=> and == to reversed forms of those same operators. Note that this is a breaking change for various C++17 code patterns, including some in use in LLVM. The most common patterns (where an operator== becomes ambiguous with a reversed form of itself) are still accepted under this patch, as an extension (with a warning). I'm hopeful that we can get the language rules fixed before C++20 ships, and the extension warning is aimed primarily at providing data to inform that decision. llvm-svn: 375306
* Implements CWG 1601 in [over.ics.rank/4.2]Richard Smith2019-10-061-0/+42
| | | | | | | | | | | | | | | | | | | Summary: The overload resolution for enums with a fixed underlying type has changed in the C++14 standard. This patch implements the new rule. Patch by Mark de Wever! Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D65695 llvm-svn: 373866
* SemaOverload - silence static analyzer getAs<> null dereference warnings. NFCI.Simon Pilgrim2019-10-021-25/+25
| | | | | | The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<> directly and if not assert will fire for us. llvm-svn: 373475
* Model converted constant expressions as full-expressions.Richard Smith2019-09-191-5/+23
| | | | | | | | | | This is groundwork for C++20's P0784R7, where non-trivial destructors can be constexpr, so we need ExprWithCleanups markers in constant expressions. No functionality change intended. llvm-svn: 372359
* [CUDA][HIP] Re-apply part of r372318.Michael Liao2019-09-191-2/+4
| | | | | | | | | | - r372318 causes violation of `use-of-uninitialized-value` detected by MemorySanitizer. Once `Viable` field is set to false, `FailureKind` needs setting as well as it will be checked during destruction if `Viable` is not true. - Revert the part trying to skip `std::vector` erasing. llvm-svn: 372356
* Revert "[CUDA][HIP] Fix typo in `BestViableFunction`"Mitch Phillips2019-09-191-9/+7
| | | | | | | | Broke the msan buildbots (see comments on rL372318 for more details). This reverts commit eb231d15825ac345b546f4c99372d1cac8f14f02. llvm-svn: 372353
* [CUDA][HIP] Fix typo in `BestViableFunction`Michael Liao2019-09-191-7/+9
| | | | | | | | | | | | | | | | | | | Summary: - Should consider viable ones only when checking SameSide candidates. - Replace erasing with clearing viable flag to reduce data moving/copying. - Add one and revise another one as the diagnostic message are more relevant compared to previous one. Reviewers: tra Subscribers: cfe-commits, yaxunl Tags: #clang Differential Revision: https://reviews.llvm.org/D67730 llvm-svn: 372318
* Merge note_ovl_builtin_candidate diagnostics; NFCSven van Haastregt2019-09-091-2/+2
| | | | | | | There is no difference between the unary and binary case, so merge them. llvm-svn: 371403
* [c++20] Implement semantic restrictions for C++20 designatedRichard Smith2019-08-301-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | initializers. This has some interesting interactions with our existing extensions to support C99 designated initializers as an extension in C++. Those are resolved as follows: * We continue to permit the full breadth of C99 designated initializers in C++, with the exception that we disallow a partial overwrite of an initializer with a non-trivially-destructible type. (Full overwrite is OK, because we won't run the first initializer at all.) * The C99 extensions are disallowed in SFINAE contexts and during overload resolution, where they could change the meaning of valid programs. * C++20 disallows reordering of initializers. We only check for that for the simple cases that the C++20 rules permit (designators of the form '.field_name =' and continue to allow reordering in other cases). It would be nice to improve this behavior in future. * All C99 designated initializer extensions produce a warning by default in C++20 mode. People are going to learn the C++ rules based on what Clang diagnoses, so it's important we diagnose these properly by default. * In C++ <= 17, we apply the C++20 rules rather than the C99 rules, and so still diagnose C99 extensions as described above. We continue to accept designated C++20-compatible initializers in C++ <= 17 silently by default (but naturally still reject under -pedantic-errors). This is not a complete implementation of P0329R4. In particular, that paper introduces new non-C99-compatible syntax { .field { init } }, and we do not support that yet. This is based on a previous patch by Don Hinton, though I've made substantial changes when addressing the above interactions. Differential Revision: https://reviews.llvm.org/D59754 llvm-svn: 370544
* clang: Fix typo in commentNico Weber2019-08-211-1/+1
| | | | | | | (Sorry for all these commits; trying to sort out why svn doesn't want to store my password.) llvm-svn: 369540
* [NFC] avoid AlignedCharArray in clangJF Bastien2019-07-291-3/+2
| | | | | | As discussed in D65249, don't use AlignedCharArray or std::aligned_storage. Just use alignas(X) char Buf[Size];. This will allow me to remove AlignedCharArray entirely, and works on the current minimum version of Visual Studio. llvm-svn: 367274
* [OpenCL] Improve destructor support in C++ for OpenCLMarco Antognini2019-07-221-3/+1
| | | | | | | This re-applies r366422 with a fix for Bug PR42665 and a new regression test. llvm-svn: 366670
* Revert r366422: [OpenCL] Improve destructor support in C++ for OpenCLIlya Biryukov2019-07-181-1/+3
| | | | | | | | Reason: this commit causes crashes in the clang compiler when building LLVM Support with libc++, see https://bugs.llvm.org/show_bug.cgi?id=42665 for details. llvm-svn: 366429
* [OpenCL] Improve destructor support in C++ for OpenCLMarco Antognini2019-07-181-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch does mainly three things: 1. It fixes a false positive error detection in Sema that is similar to D62156. The error happens when explicitly calling an overloaded destructor for different address spaces. 2. It selects the correct destructor when multiple overloads for address spaces are available. 3. It inserts the expected address space cast when invoking a destructor, if needed, and therefore fixes a crash due to the unmet assertion in llvm::CastInst::Create. The following is a reproducer of the three issues: struct MyType { ~MyType() {} ~MyType() __constant {} }; __constant MyType myGlobal{}; kernel void foo() { myGlobal.~MyType(); // 1 and 2. // 1. error: cannot initialize object parameter of type // '__generic MyType' with an expression of type '__constant MyType' // 2. error: no matching member function for call to '~MyType' } kernel void bar() { // 3. The implicit call to the destructor crashes due to: // Assertion `castIsValid(op, S, Ty) && "Invalid cast!"' failed. // in llvm::CastInst::Create. MyType myLocal; } The added test depends on D62413 and covers a few more things than the above reproducer. Subscribers: yaxunl, Anastasia, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64569 llvm-svn: 366422
* [OpenCL] Fixing sampler initialisations for C++ mode.Neil Hickey2019-07-161-0/+4
| | | | | | | | Allow conversions between integer and sampler type. Differential Revision: https://reviews.llvm.org/D64791 llvm-svn: 366212
* Fix parameter name comments using clang-tidy. NFC.Rui Ueyama2019-07-161-22/+22
| | | | | | | | | | | | | | | | | | | | | This patch applies clang-tidy's bugprone-argument-comment tool to LLVM, clang and lld source trees. Here is how I created this patch: $ git clone https://github.com/llvm/llvm-project.git $ cd llvm-project $ mkdir build $ cd build $ cmake -GNinja -DCMAKE_BUILD_TYPE=Debug \ -DLLVM_ENABLE_PROJECTS='clang;lld;clang-tools-extra' \ -DCMAKE_EXPORT_COMPILE_COMMANDS=On -DLLVM_ENABLE_LLD=On \ -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ ../llvm $ ninja $ parallel clang-tidy -checks='-*,bugprone-argument-comment' \ -config='{CheckOptions: [{key: StrictMode, value: 1}]}' -fix \ ::: ../llvm/lib/**/*.{cpp,h} ../clang/lib/**/*.{cpp,h} ../lld/**/*.{cpp,h} llvm-svn: 366177
* [Sema] Diagnose addr space mismatch while constructing objectsAnastasia Stulova2019-06-201-2/+24
| | | | | | | | | | | | | | If we construct an object in some arbitrary non-default addr space it should fail unless either: - There is an implicit conversion from the address space to default /generic address space. - There is a matching ctor qualified with an address space that is either exactly matching or convertible to the address space of an object. Differential Revision: https://reviews.llvm.org/D62156 llvm-svn: 363944
* [clang] Add storage for APValue in ConstantExprGauthier Harnisch2019-06-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When using ConstantExpr we often need the result of the expression to be kept in the AST. Currently this is done on a by the node that needs the result and has been done multiple times for enumerator, for constexpr variables... . This patch adds to ConstantExpr the ability to store the result of evaluating the expression. no functional changes expected. Changes: - Add trailling object to ConstantExpr that can hold an APValue or an uint64_t. the uint64_t is here because most ConstantExpr yield integral values so there is an optimized layout for integral values. - Add basic* serialization support for the trailing result. - Move conversion functions from an enum to a fltSemantics from clang::FloatingLiteral to llvm::APFloatBase. this change is to make it usable for serializing APValues. - Add basic* Import support for the trailing result. - ConstantExpr created in CheckConvertedConstantExpression now stores the result in the ConstantExpr Node. - Adapt AST dump to print the result when present. basic* : None, Indeterminate, Int, Float, FixedPoint, ComplexInt, ComplexFloat, the result is not yet used anywhere but for -ast-dump. Reviewers: rsmith, martong, shafik Reviewed By: rsmith Subscribers: rnkovacs, hiraditya, dexonsmith, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D62399 llvm-svn: 363493
* Factor out duplicated code building a MemberExpr and marking itRichard Smith2019-06-061-7/+4
| | | | | | | | referenced. This reinstates r362563, reverted in r362597. llvm-svn: 362757
* Revert "Factor out duplicated code building a MemberExpr and marking it" and ↵Benjamin Kramer2019-06-051-4/+7
| | | | | | | | "Convert MemberExpr creation and serialization to work the same way as" This reverts commits r362551 and r362563. Crashes during modules selfhost. llvm-svn: 362597
* Factor out duplicated code building a MemberExpr and marking itRichard Smith2019-06-051-7/+4
| | | | | | referenced. llvm-svn: 362563
* Factor out repeated code to build a DeclRefExpr and mark it referenced.Richard Smith2019-06-041-22/+8
| | | | llvm-svn: 362537
* Factor out repeated code to build 'this' expressions and mark themRichard Smith2019-05-241-4/+2
| | | | | | referenced. llvm-svn: 361588
* Added an assertion to constant evaluation enty points that prohibits ↵Dmitri Gribenko2019-05-171-2/+4
| | | | | | | | | | | | | | | | | | dependent expressions Summary: Constant evaluator does not work on value-dependent or type-dependent expressions. Also fixed bugs uncovered by these assertions. Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D61522 llvm-svn: 361050
* Fix regression in r360311 caused by reversed bool arguments.Richard Smith2019-05-161-1/+2
| | | | llvm-svn: 360837
* [c++20] Add support for explicit(bool), as described in P0892R2.Richard Smith2019-05-091-63/+108
| | | | | | | | Patch by Tyker! Differential Revision: https://reviews.llvm.org/D60934 llvm-svn: 360311
* [c++20] Implement P0846R0: allow (ADL-only) calls to template-ids whoseRichard Smith2019-05-091-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | template name is not visible to unqualified lookup. In order to support this without a severe degradation in our ability to diagnose typos in template names, this change significantly restructures the way we handle template-id-shaped syntax for which lookup of the template name finds nothing. Instead of eagerly diagnosing an undeclared template name, we now form a placeholder template-name representing a name that is known to not find any templates. When the parser sees such a name, it attempts to disambiguate whether we have a less-than comparison or a template-id. Any diagnostics or typo-correction for the name are delayed until its point of use. The upshot should be a small improvement of our diagostic quality overall: we now take more syntactic context into account when trying to resolve an undeclared identifier on the left hand side of a '<'. In fact, this works well enough that the backwards-compatible portion (for an undeclared identifier rather than a lookup that finds functions but no function templates) is enabled in all language modes. llvm-svn: 360308
* Split ActOnCallExpr into an ActOnCallExpr to be called by the parser,Richard Smith2019-05-081-4/+4
| | | | | | | and a BuildCallExpr to be called internally within Sema to build / rebuild calls. llvm-svn: 360217
* Revert r359949 "[clang] adding explicit(bool) from c++2a"Hans Wennborg2019-05-061-110/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This caused Clang to start erroring on the following: struct S {   template <typename = int> explicit S(); }; struct T : S {}; struct U : T {   U(); }; U::U() {} $ clang -c /tmp/x.cc /tmp/x.cc:10:4: error: call to implicitly-deleted default constructor of 'T' U::U() {}    ^ /tmp/x.cc:5:12: note: default constructor of 'T' is implicitly deleted because base class 'S' has no default constructor struct T : S {};            ^ 1 error generated. See discussion on the cfe-commits email thread. This also reverts the follow-ups r359966 and r359968. > this patch adds support for the explicit bool specifier. > > Changes: > - The parsing for the explicit(bool) specifier was added in ParseDecl.cpp. > - The storage of the explicit specifier was changed. the explicit specifier was stored as a boolean value in the FunctionDeclBitfields and in the DeclSpec class. now it is stored as a PointerIntPair<Expr*, 2> with a flag and a potential expression in CXXConstructorDecl, CXXDeductionGuideDecl, CXXConversionDecl and in the DeclSpec class. > - Following the AST change, Serialization, ASTMatchers, ASTComparator and ASTPrinter were adapted. > - Template instantiation was adapted to instantiate the potential expressions of the explicit(bool) specifier When instantiating their associated declaration. > - The Add*Candidate functions were adapted, they now take a Boolean indicating if the context allowing explicit constructor or conversion function and this boolean is used to remove invalid overloads that required template instantiation to be detected. > - Test for Semantic and Serialization were added. > > This patch is not yet complete. I still need to check that interaction with CTAD and deduction guides is correct. and add more tests for AST operations. But I wanted first feedback. > Perhaps this patch should be spited in smaller patches, but making each patch testable as a standalone may be tricky. > > Patch by Tyker > > Differential Revision: https://reviews.llvm.org/D60934 llvm-svn: 360024
* [clang] adding explicit(bool) from c++2aNicolas Lesser2019-05-041-63/+110
| | | | | | | | | | | | | | | | | | | | | this patch adds support for the explicit bool specifier. Changes: - The parsing for the explicit(bool) specifier was added in ParseDecl.cpp. - The storage of the explicit specifier was changed. the explicit specifier was stored as a boolean value in the FunctionDeclBitfields and in the DeclSpec class. now it is stored as a PointerIntPair<Expr*, 2> with a flag and a potential expression in CXXConstructorDecl, CXXDeductionGuideDecl, CXXConversionDecl and in the DeclSpec class. - Following the AST change, Serialization, ASTMatchers, ASTComparator and ASTPrinter were adapted. - Template instantiation was adapted to instantiate the potential expressions of the explicit(bool) specifier When instantiating their associated declaration. - The Add*Candidate functions were adapted, they now take a Boolean indicating if the context allowing explicit constructor or conversion function and this boolean is used to remove invalid overloads that required template instantiation to be detected. - Test for Semantic and Serialization were added. This patch is not yet complete. I still need to check that interaction with CTAD and deduction guides is correct. and add more tests for AST operations. But I wanted first feedback. Perhaps this patch should be spited in smaller patches, but making each patch testable as a standalone may be tricky. Patch by Tyker Differential Revision: https://reviews.llvm.org/D60934 llvm-svn: 359949
* SemaOverload: Complete candidates before emitting the error, to ensure ↵David Blaikie2019-05-031-102/+167
| | | | | | | | | | | | | | | | | diagnostics emitted (or suppressed) during completion don't interfere with the overload notes Because diagnostics and their notes are not connected at the API level, if the error message for an overload is emitted, then the overload candidates are completed - if a diagnostic is emitted during that work, the notes related to overload candidates would be attached to the latter diagnostic, not the original error. Sort of worse, if the latter diagnostic was disabled, the notes are disabled. Reviewers: rsmith Differential Revision: https://reviews.llvm.org/D61357 llvm-svn: 359854
* [OpenCL] Fix initialisation of this via pointer.Anastasia Stulova2019-05-021-5/+5
| | | | | | | | | | | | | | | When the expression used to initialise 'this' has a pointer type, check the address space of the pointee type instead of the pointer type to decide whether an address space cast is required. It is the pointee type that carries the address space qualifier. Fixing PR41674. Patch by kpet (Kevin Petit)! Differential Revision: https://reviews.llvm.org/D61319 llvm-svn: 359798
* Diagnose non-dependent qualified friend function template declarationsRichard Smith2019-05-021-0/+1
| | | | | | | that don't match any existing declaration. Don't get confused and treat such declarations as template *specializations*. llvm-svn: 359746
* Use llvm::stable_sortFangrui Song2019-04-241-2/+2
| | | | llvm-svn: 359098
* [Sema][NFCI] Don't allocate storage for the various ↵Bruno Ricci2019-03-251-19/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CorrectionCandidateCallback unless we are going to do some typo correction The various CorrectionCandidateCallbacks are currently heap-allocated unconditionally. This was needed because of delayed typo correction. However these allocations represent currently 15.4% of all allocations (number of allocations) when parsing all of Boost (!), mostly because of ParseCastExpression, ParseStatementOrDeclarationAfterAttrtibutes and isCXXDeclarationSpecifier. Note that all of these callback objects are small. Let's not do this. Instead initially allocate the callback on the stack, and only do a heap allocation if we are going to do some typo correction. Do this by: 1. Adding a clone function to each callback, which will do a polymorphic clone of the callback. This clone function is required to be implemented by every callback (of which there is a fair amount). Make sure this is the case by making it pure virtual. 2. Use this clone function when we are going to try to correct a typo. This additionally cut the time of -fsyntax-only on all of Boost by 0.5% (not that much, but still something). No functional changes intended. Differential Revision: https://reviews.llvm.org/D58827 Reviewed By: rnk llvm-svn: 356925
* [Sema] Deduplicate some availability checking logicErik Pilkington2019-03-201-50/+11
| | | | | | | | | | | | | | | Before this commit, we emit unavailable errors for calls to functions during overload resolution, and for references to all other declarations in DiagnoseUseOfDecl. The early checks during overload resolution aren't as good as the DiagnoseAvailabilityOfDecl based checks, as they error on the code from PR40991. This commit fixes this by removing the early checking. llvm.org/PR40991 rdar://48564179 Differential revision: https://reviews.llvm.org/D59394 llvm-svn: 356599
* [Sema] Adjust addr space of reference operand in compound assignmentAnastasia Stulova2019-03-191-10/+8
| | | | | | | | | | When we create overloads for the builtin compound assignment operators we need to preserve address space for the reference operand taking it from the argument that is passed in. Differential Revision: https://reviews.llvm.org/D59367 llvm-svn: 356475
* [PR40778][Sema] Adjust addr space of operands in builtin operators.Anastasia Stulova2019-03-071-5/+14
| | | | | | | | | | | | Adjust address space for references and pointer operands of builtin operators. Currently this change only fixes addr space in assignment (= and |=) operator, that is needed for the test case reported in the bug. Wider support for all other operations will follow. Differential Revision: https://reviews.llvm.org/D58719 llvm-svn: 355608
* Rename getTypeQualifiers to getMethodQualifiers.Anastasia Stulova2019-01-281-9/+9
| | | | | | | | Use more descriptive name for the method qualifiers getter. Differential Revision: https://reviews.llvm.org/D56792 llvm-svn: 352349
* [AST] Pack GenericSelectionExprBruno Ricci2019-01-261-1/+1
| | | | | | | | | | | | | | | | Store the controlling expression, the association expressions and the corresponding TypeSourceInfos as trailing objects. Additionally use the bit-fields of Stmt to store one SourceLocation, saving one additional pointer. This saves 3 pointers in total per GenericSelectionExpr. Differential Revision: https://reviews.llvm.org/D57104 Reviewed By: aaron.ballman Reviewers: aaron.ballman, steveire llvm-svn: 352276
* [OpenCL] Allow address spaces as method qualifiers.Anastasia Stulova2019-01-211-7/+15
| | | | | | | | | | | | | | | Methods can now be qualified with address spaces to prevent undesirable conversions to generic or to provide custom implementation to be used if the object is located in certain memory segments. This commit extends parsing and standard C++ overloading to work for an address space of a method (i.e. implicit 'this' parameter). Differential Revision: https://reviews.llvm.org/D55850 llvm-svn: 351747
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [OpenCL] Fix overloading ranking rules for addrspace conversions.Anastasia Stulova2019-01-181-1/+4
| | | | | | | | | Extend ranking to work with address spaces correctly when resolving overloads. Differential Revision: https://reviews.llvm.org/D56735 llvm-svn: 351546
* Remember to instantiate explicit template argument lists in a friendRichard Smith2019-01-111-0/+1
| | | | | | | | | | | | | | | function declaration. We'd previously often just drop these on the floor, and friend redeclaration matching would usually (but not always) figure out the right redeclaration anyway. Also, don't try to match a dependent friend function template specialization to a template until instantiation, and don't forget to reject qualified friend declarations in dependent contexts that don't name an already-declared entity. llvm-svn: 350915
* [AST] Remove ASTContext from getThisType (NFC)Brian Gesiak2019-01-111-4/+4
| | | | | | | | | | | | | | | | | | | | | Summary: https://reviews.llvm.org/D54862 removed the usages of `ASTContext&` from within the `CXXMethodDecl::getThisType` method. Remove the parameter altogether, as well as all usages of it. This does not result in any functional change because the parameter was unused since https://reviews.llvm.org/D54862. Test Plan: check-clang Reviewers: akyrtzi, mikael Reviewed By: mikael Subscribers: mehdi_amini, dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D56509 llvm-svn: 350914
OpenPOWER on IntegriCloud