summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaOverload.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [OpenCL] Restrict addr space conversions in nested pointersAnastasia Stulova2020-02-121-10/+14
| | | | | | | | | | | | | | | | | | | | | | Address space conversion changes pointer representation. This commit disallows such conversions when they are not legal i.e. for the nested pointers even with compatible address spaces. Because the address space conversion in the nested levels can't be generated to modify the pointers correctly. The behavior implemented is as follows: - Any implicit conversions of nested pointers with different address spaces is rejected. - Any conversion of address spaces in nested pointers in safe casts (e.g. const_cast or static_cast) is rejected. - Conversion in low level C-style or reinterpret_cast is accepted but with a warning (this aligns with OpenCL C behavior). Fixes PR39674 Differential Revision: https://reviews.llvm.org/D73360 (cherry picked from commit 6064f426a18304e16b51cc79e74c9c2d55ef5a9c)
* PR44761: Fix fallback to later tiebreakers if two non-template functionsRichard Smith2020-02-041-8/+6
| | | | | | are equally constrained. (cherry picked from commit cfacf9ae20b8c97a428f118a2720bc109ba6a143)
* PR44627: Consider reversing == and <=> candidates found by ADL.Richard Smith2020-01-301-8/+22
| | | | (cherry picked from commit 1db66e705f4dbe7dbe17edac804289ef59d5f616)
* [Concepts] Transform constraints of non-template functions to ConstantEvaluatedSaar Raz2020-01-251-11/+9
| | | | | | | | | | We would previously try to evaluate atomic constraints of non-template functions as-is, and since they are now unevaluated at first, this would cause incorrect evaluation (bugs #44657, #44656). Substitute into atomic constraints of non-template functions as we would atomic constraints of template functions, in order to rebuild the expressions in a constant-evaluated context. (cherry picked from commit 713562f54858f10bf8998ee21ff2c7e7bad0d177)
* Fix "pointer is null" clang static analyzer warnings. NFCI.Simon Pilgrim2020-01-141-23/+14
| | | | Use cast<>/castAs<> instead of dyn_cast<>/getAs<> since the pointers are always dereferenced and cast<>/castAs<> will perform the null assertion for us.
* Sema::getOwningModule - take const Decl* type.Simon Pilgrim2020-01-131-4/+3
| | | | Fixes static analyzer warning that const_cast was being used despite only const methods being called.
* CWG2352: Allow qualification conversions during reference binding.Richard Smith2020-01-091-129/+153
| | | | | | | | | | | | | | | | | | | | | | The language wording change forgot to update overload resolution to rank implicit conversion sequences based on qualification conversions in reference bindings. The anticipated resolution for that oversight is implemented here -- we order candidates based on qualification conversion, not only on top-level cv-qualifiers, including ranking reference bindings against non-reference bindings if they differ in non-top-level qualification conversions. For OpenCL/C++, this allows reference binding between pointers with differing (nested) address spaces. This makes the behavior of reference binding consistent with that of implicit pointer conversions, as is the purpose of this change, but that pre-existing behavior for pointer conversions is itself probably not correct. In any case, it's now consistently the same behavior and implemented in only one place. This reinstates commit de21704ba96fa80d3e9402f12c6505917a3885f4, reverted in commit d8018233d1ea4234de68d5b4593abd773db79484, with workarounds for some overload resolution ordering problems introduced by CWG2352.
* When diagnosing the lack of a viable conversion function, also listRichard Smith2020-01-091-68/+120
| | | | | | | | | | | | | | explicit functions that are not candidates. It's not always obvious that the reason a conversion was not possible is because the function you wanted to call is 'explicit', so explicitly say if that's the case. It would be nice to rank the explicit candidates higher in the diagnostic if an implicit conversion sequence exists for their arguments, but unfortunately we can't determine that without potentially triggering non-immediate-context errors that we're not permitted to produce.
* [Concepts] Function trailing requires clausesSaar Raz2020-01-091-26/+229
| | | | | | Function trailing requires clauses now parsed, supported in overload resolution and when calling, referencing and taking the address of functions or function templates. Differential Revision: https://reviews.llvm.org/D43357
* Always deduce the lengths of contained parameter packs when deducing aRichard Smith2020-01-061-0/+16
| | | | | | | | | | | | | | | | | pack expansion. Previously, if all parameter / argument pairs for a pack expansion deduction were non-deduced contexts, we would not deduce the arity of the pack, and could end up deducing a different arity (leading to failures during substitution) or defaulting to an arity of 0 (leading to bad diagnostics about passing the wrong number of arguments to a variadic function). Instead, we now always deduce the arity for all involved packs any time we deduce a pack expansion. This will result in less substitution happening in some cases, which could avoid non-SFINAEable errors, and should generally improve the quality of diagnostics when passing initializer lists to variadic functions.
* Revert "CWG2352: Allow qualification conversions during reference binding."David Blaikie2019-12-271-155/+135
| | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit de21704ba96fa80d3e9402f12c6505917a3885f4. Regressed/causes this to error due to ambiguity: void f(const int * const &); void f(int *); int main() { int * x; f(x); } (in case it's important - the original case where this turned up was a member function overload in a class template with, essentially: f(const T1&) f(T2*) (where T1 == X const *, T2 == X)) It's not super clear to me if this ^ is expected behavior, in which case I'm sorry about the revert & happy to look into ways to fix the original code.
* CWG2352: Allow qualification conversions during reference binding.Richard Smith2019-12-191-135/+155
| | | | | | | | | | | | | | | The language wording change forgot to update overload resolution to rank implicit conversion sequences based on qualification conversions in reference bindings. The anticipated resolution for that oversight is implemented here -- we order candidates based on qualification conversion, not only on top-level cv-qualifiers. For OpenCL/C++, this allows reference binding between pointers with differing (nested) address spaces. This makes the behavior of reference binding consistent with that of implicit pointer conversions, as is the purpose of this change, but that pre-existing behavior for pointer conversions is itself probably not correct. In any case, it's now consistently the same behavior and implemented in only one place.
* Refactor CompareReferenceRelationship and its callers in preparation forRichard Smith2019-12-181-74/+50
| | | | | | | | | | | | | | implementing the resolution of CWG2352. No functionality change, except that we now convert the referent of a reference binding to the underlying type of the reference in more cases; we used to happen to preserve the type sugar from the referent if the only type change was in the cv-qualifiers. This exposed a bug in how we generate code for trivial assignment operators: if the type sugar (particularly the may_alias attribute) got lost during reference binding, we'd use the "wrong" TBAA information for the load during the assignment.
* Add support for the MS qualifiers __ptr32, __ptr64, __sptr, __uptr.Amy Huang2019-12-181-2/+6
| | | | | | | | | | | | | | | | | | | | Summary: This adds parsing of the qualifiers __ptr32, __ptr64, __sptr, and __uptr and lowers them to the corresponding address space pointer for 32-bit and 64-bit pointers. (32/64-bit pointers added in https://reviews.llvm.org/D69639) A large part of this patch is making these pointers ignore the address space when doing things like overloading and casting. https://bugs.llvm.org/show_bug.cgi?id=42359 Reviewers: rnk, rsmith Subscribers: jholewinski, jvesely, nhaehnle, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D71039
* [c++20] P1959R0: Remove support for std::*_equality.Richard Smith2019-12-161-19/+6
|
* Resolve exception specifications after marking the correspondingRichard Smith2019-12-151-9/+6
| | | | | | | | function as referenced, not before. No functionality change intended. This is groundwork for computing the exception specification of a defaulted comparison, for which we'd like to use the implicit body where possible.
* [Sema] Improve diagnostic about addr spaces for overload candidatesAnastasia Stulova2019-12-131-4/+11
| | | | | | | | | | Allow sending address spaces into diagnostics to simplify and improve error reporting. Improved wording of diagnostics for address spaces in overloading. Tags: #clang Differential Revision: https://reviews.llvm.org/D71111
* [c++20] Implement P1185R2 (as modified by P2002R0).Richard Smith2019-12-101-0/+4
| | | | | | For each defaulted operator<=> in a class that doesn't explicitly declare any operator==, also inject a matching implicit defaulted operator==.
* [c++20] Synthesis of defaulted comparison functions.Richard Smith2019-12-081-1/+125
| | | | | | Array members are not yet handled. In addition, defaulted comparisons can't yet find comparison operators by unqualified lookup (only by member lookup and ADL). These issues will be fixed in follow-on changes.
* [c++20] Determine whether a defaulted comparison should be deleted orRichard Smith2019-12-061-62/+80
| | | | constexpr.
* Add `QualType::hasAddressSpace`. NFC.Michael Liao2019-12-061-1/+1
| | | | | - Add that as a shorthand of <T>.getQualifiers().hasAddressSpace(). - Simplify related code.
* [Concepts] Constraint Enforcement & DiagnosticsSaar Raz2019-12-061-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 Re-commit, after fixing some memory bugs.
* [NFC] Supress GCC "Bitfield too small to hold all values of enum" warning.Richard Smith2019-11-091-8/+8
| | | | | | Patch by Wang Tianqing! Differential Revision: https://reviews.llvm.org/D69792
* [OpenCL] Fix address space for const method call from nonconst (PR43145)Sven van Haastregt2019-11-041-1/+4
| | | | | | Patch by Anastasia Stulova and Sven van Haastregt. Differential Revision: https://reviews.llvm.org/D68781
* 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
OpenPOWER on IntegriCloud