summaryrefslogtreecommitdiff
path: root/lib/Sema/SemaOverload.cpp
Commit message (Collapse)AuthorAgeFilesLines
* 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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375313 91177308-0d34-0410-b5e6-96231b3b80d8
* [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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375306 91177308-0d34-0410-b5e6-96231b3b80d8
* 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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@373866 91177308-0d34-0410-b5e6-96231b3b80d8
* 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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@373475 91177308-0d34-0410-b5e6-96231b3b80d8
* 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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@372359 91177308-0d34-0410-b5e6-96231b3b80d8
* [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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@372356 91177308-0d34-0410-b5e6-96231b3b80d8
* 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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@372353 91177308-0d34-0410-b5e6-96231b3b80d8
* [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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@372318 91177308-0d34-0410-b5e6-96231b3b80d8
* 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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@371403 91177308-0d34-0410-b5e6-96231b3b80d8
* [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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@370544 91177308-0d34-0410-b5e6-96231b3b80d8
* 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.) git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@369540 91177308-0d34-0410-b5e6-96231b3b80d8
* [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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@367274 91177308-0d34-0410-b5e6-96231b3b80d8
* [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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@366670 91177308-0d34-0410-b5e6-96231b3b80d8
* 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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@366429 91177308-0d34-0410-b5e6-96231b3b80d8
* [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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@366422 91177308-0d34-0410-b5e6-96231b3b80d8
* [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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@366212 91177308-0d34-0410-b5e6-96231b3b80d8
* 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} git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@366177 91177308-0d34-0410-b5e6-96231b3b80d8
* [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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@363944 91177308-0d34-0410-b5e6-96231b3b80d8
* [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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@363493 91177308-0d34-0410-b5e6-96231b3b80d8
* Factor out duplicated code building a MemberExpr and marking itRichard Smith2019-06-061-7/+4
| | | | | | | | referenced. This reinstates r362563, reverted in r362597. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@362757 91177308-0d34-0410-b5e6-96231b3b80d8
* 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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@362597 91177308-0d34-0410-b5e6-96231b3b80d8
* Factor out duplicated code building a MemberExpr and marking itRichard Smith2019-06-051-7/+4
| | | | | | referenced. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@362563 91177308-0d34-0410-b5e6-96231b3b80d8
* Factor out repeated code to build a DeclRefExpr and mark it referenced.Richard Smith2019-06-041-22/+8
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@362537 91177308-0d34-0410-b5e6-96231b3b80d8
* Factor out repeated code to build 'this' expressions and mark themRichard Smith2019-05-241-4/+2
| | | | | | referenced. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@361588 91177308-0d34-0410-b5e6-96231b3b80d8
* 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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@361050 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix regression in r360311 caused by reversed bool arguments.Richard Smith2019-05-161-1/+2
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@360837 91177308-0d34-0410-b5e6-96231b3b80d8
* [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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@360311 91177308-0d34-0410-b5e6-96231b3b80d8
* [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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@360308 91177308-0d34-0410-b5e6-96231b3b80d8
* 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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@360217 91177308-0d34-0410-b5e6-96231b3b80d8
* 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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@360024 91177308-0d34-0410-b5e6-96231b3b80d8
* [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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359949 91177308-0d34-0410-b5e6-96231b3b80d8
* 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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359854 91177308-0d34-0410-b5e6-96231b3b80d8
* [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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359798 91177308-0d34-0410-b5e6-96231b3b80d8
* 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*. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359746 91177308-0d34-0410-b5e6-96231b3b80d8
* Use llvm::stable_sortFangrui Song2019-04-241-2/+2
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359098 91177308-0d34-0410-b5e6-96231b3b80d8
* [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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@356925 91177308-0d34-0410-b5e6-96231b3b80d8
* [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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@356599 91177308-0d34-0410-b5e6-96231b3b80d8
* [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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@356475 91177308-0d34-0410-b5e6-96231b3b80d8
* [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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@355608 91177308-0d34-0410-b5e6-96231b3b80d8
* 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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@352349 91177308-0d34-0410-b5e6-96231b3b80d8
* [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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@352276 91177308-0d34-0410-b5e6-96231b3b80d8
* [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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@351747 91177308-0d34-0410-b5e6-96231b3b80d8
* 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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@351636 91177308-0d34-0410-b5e6-96231b3b80d8
* [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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@351546 91177308-0d34-0410-b5e6-96231b3b80d8
* 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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@350915 91177308-0d34-0410-b5e6-96231b3b80d8
* [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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@350914 91177308-0d34-0410-b5e6-96231b3b80d8
* DR674, PR38883, PR40238: Qualified friend lookup should look for aRichard Smith2019-01-071-0/+29
| | | | | | | | | | | | | | | | | | template specialization if there is no matching non-template function. This exposed a couple of related bugs: - we would sometimes substitute into a friend template instead of a suitable non-friend declaration; this would now crash because we'd decide the specialization of the friend is a redeclaration of itself - ADL failed to properly handle the case where an invisible local extern declaration redeclares an invisible friend Both are fixed herein: in particular, we now never make invisible friends or local extern declarations visible to name lookup unless they are the only declaration of the entity. (We already mostly did this for local extern declarations.) git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@350505 91177308-0d34-0410-b5e6-96231b3b80d8
* Prevent unreachable when checking invalid multiversion decls.Erich Keane2019-01-041-0/+5
| | | | | | | | | | | | CPUSpecifc/CPUDispatch call resolution assumed that all declarations that would be passed are valid, however this was an invalid assumption. This patch deals with those situations by making the valid version take priority. Note that the checked ordering is arbitrary, since both are replaced by calls to the resolver later. Change-Id: I7ff2ec88c55a721d51bc1f39ea1a1fe242b4e45f git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@350398 91177308-0d34-0410-b5e6-96231b3b80d8
* [Basic] Extend DiagnosticEngine to store and format Qualifiers.Anastasia Stulova2019-01-041-5/+3
| | | | | | | | | | | | | Qualifiers can now be streamed into the DiagnosticEngine using regular << operator. If Qualifiers are empty 'unqualified' will be printed in the diagnostic otherwise regular qual syntax is used. Differential Revision: https://reviews.llvm.org/D56198 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@350386 91177308-0d34-0410-b5e6-96231b3b80d8
* [AST] Store the callee and argument expressions of CallExpr in a trailing array.Bruno Ricci2018-12-211-60/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@349910 91177308-0d34-0410-b5e6-96231b3b80d8
View Lorry Controller Status